The only way to have two servers up and available with the same name is to have 2 domains. The production domain and the DR domain.
In order for that to work, you also have to make sure the domains are fully trusted so any authentication done on prod domain will be trusted on the DR domain.
There is value to having multiple domains - where you can then have a dev/test domain, prod domain, DR domain, etc... This allows for segmenting the servers and can isolate things very nicely. However, in order to be able to do something like this you have to have a networking and AD team that really understand the setup and can manage it.
With that said, it is not necessary to do that to bring up a cloned server. During the cloning process - when the new server is being built your server team can rename the server, setup a new IP address, etc...
This will break SQL Server, but that is easy to fix with a simple drop server and add server.
Note: since this is going to your DR site, you probably cannot do a straight clone. You probably have to export the image and import the image onto the VM farm in your DR site. This requires a server downtime - your server team will need to take the server offline.
Either way - you will need SQL Server down to perform the clone or you may well find that the database files are corrupted and unusable.
So, as a DR strategy this doesn't work - for DR you will need to look at mirroring, log shipping or SAN replication as options. But, you can do any of these once you have a server setup in your DR site.
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster
Managing Transaction Logs