This is not possible. As the Event log states, you must join a domain for this to work. The Active Directory domain name is used as the DNS domain name for the system.
As soon as we recreated the configuration with the DHCP/DNS server joined to Active Directory, it all worked.
It sounds like your "Desktop Support" group has excessive rights, which allow members to overwrite attributes on existing computer accounts.
There's no specific functionality to prevent joining computers with existing names. By not delegating the "Desktop Support" group rights to modify existing computer objects you remove the ability for group members to modify existing computer objects.
If I were you I'd do the following:
Create an OU in your Active Directory for newly-created computer accounts to "land" in (when created with the default GUI domain join functionality in the client OS). I'm going to call this the "New Computers" OU.
Redirect the default "Computers" container to the "New Computers" OU using the redircmp utility (Microsoft has specific usage details)
Delegate the "Desktop Support" group rights to "Create Computer Objects" to the "New Computers" OU.
Members of the "Desktop Support" group will be able to join computers to the domain and the newly-created computer objects will end up in the "New Computers" OU. They will not, assuming you've removed the users' memberships in any higher-privileged groups, be able to modify existing computer objects and, thus, will not be able to join computers to the domain with names that are used by computers joined to the domain already.
Edit:
I am not able to reproduce the behavior you're seeing re: "...an error about not being able to change the Primary Domain DNS Name".
Be aware that the default permissions set on computer objects when you're testing the behavior of the product. The account you use to create the computer object is set as the owner and granted permission (as CREATOR OWNER) to the newly-created object. If you're using the same account to add the "conflicting" computer these permissions are going to allow you to "break" the original computer account. I'm not aware of any way to override this behavior. Your best bet to prevent this behavior from causing problems would be to programmatically reset the owner on newly-created computer objects to "Administrators" and re-apply the default ACL (to remove the ACEs that refer to the original CREATOR OWNER).
I joined a machine named "TEST-SVR01" to my test domain using a member of my "Desktop Support" group. After I did that I reset the ownership on the TEST-SVR01 computer object to "Administrators" and re-applied the default permissions (using the "Default" button on the "Advanced" security dialog).
I attempted to join another machine named TEST-SVR01 to the domain using the same "Desktop Support"-member user and got the error message "Access is denied" during the attempt. The original TEST-SVR01 still had an intact trust relationship with the domain.
There is no simple (or, in my opinion, advisable) way to make "Domain Admins" group members unable to alter existing computer accounts. You could probably do something sickening with "Deny" permissions but you're going to make the product behave in a manner very different from its default. I'd argue that you shouldn't be using "Domain Admins"-member accounts to join computers to the domain. The principle of least privilege dictates that you should only be using "Domain Admins"-member accounts to perform functions for which their excessive rights are necessary, and joining computers to the domain doesn't needthose excessive rights.
Best Answer
If you already have a computer account on the domain by another name, I'm fairly certain you won't be able to join with a 2nd computer of the same name. You may also want to research SIDs (Security ID) to make sure you're not trying to use two computers with matching SIDs on the same domain.