You should be using DFS namespaces (DFS-N). A domain based path like \contoso.com\Data can be used to organize data like \contoso.com\Data\HR, \contoso.com\Data\Accounting etc. You then use DFS-R to keep two copies of each set of data on your two servers. i.e. \contoso.com\Data\HR will exist as \Server1\HR and \Server2\HR.
DFS-N is like DNS for file shares. When folk ask for \contoso.com\Data\HR, they get redirected to either \server1\HR or \Server2\HR based on the configuration and how referrals are sorted.
See http://blogs.technet.com/b/josebda/archive/2009/08/21/three-ways-to-design-your-dfs-namespaces.aspx
You don't ever tell users to connect to shares by the literal server name. That way, you can change the underlying paths and servers without issue while still ensuring users access data using paths that remain static.
If you implement DFS-N and DFS-R together, then you wont need to swap servers with same name and IP.
I haven't verified yet if dfsradmin.exe requires the servers to exist before it does cleanup. So I wasnt expecting the behaviour you report.
dfsradmin is essentially deleting AD objects when you use it to delete connections etc. You can use any AD tools like dsrm.exe, ldifde.exe or powershell cmdlets like remove-adobject to do the cleanup if you have to. DFSR has objects under two locations. Remember you have common topology related config under CN=DFSR-Globalsettings,CN=System,DC=contoso,DC=com and server specific config under locations like cn=DFSR-LocalSettings,CN=2008R2-MIG-01,Ou=Servers,DC=contoso,DC=com. So ideally you need to cleanup and remove what you don't need from both places when decommissioning a server if you want to "keep it neat".
Obviously you can also do this all in the GUI. But I assume you want to script this.
