Moving databases between environments has always been supported. You couldn't run a DTAP street properly without that capability. Mostly, Content Porter is used to move templates and the like forwards towards Production, and database backups/restores are used (less frequently) to bring realistic production data back towards the Development environment. Of course, you get the exact same database, which won't be suitable for your environment, so you'll need to fix some things.
Firstly, to address your question directly: you can add and delete users to/from a newly restored database just as you would with any other Tridion system. When adding users via the GUI you rely on choosing from a list of users in the local domain (or configured LDAP server), but there is no such restriction at an API level. You can use a power tool to add a user from a different domain, but mostly it's more convenient to simply script it. (There's an example of using PowerShell/Core Service to add a group and a user on my blog post about setting rights and permissions)
The first thing you'll need when you restore your database is an administrator account in the domain where your restored system runs. Often this is in a different domain from where the backup was made, so in this case, it makes sense to create the administrator account before you make the backup. You may find it convenient to have administrator accounts for all your environments in your production database. (Some security policies won't allow this, but you may be able to add an account before making the backup and remove it immediately afterwards.)
Another good thing to do before making the backup is to shut down the various Tridion services, or at least the ones which subscribe to queues. These services will unsubscribe themselves as queue consumers on shutdown, which means that your backup won't have queue consumer records relating to the wrong environment. (If this won't work, ask support for a database script that cleans this up in a supported manner.)
As others have noted, you'll also need to deal with publication targets and other things, most of which can be scripted easily enough. The most important of these is that the content manager's view of what is published will be wrong. You'll want to delete published items from your file system, install clean broker databases, and set the publish state in the content manager to unpublished before publishing from your restored system as appropriate. The correct way of doing this differs from one version of Tridion to the next, but in 2013SP1 you can simply decommission the target.
