It turns out the above is indeed possible but only with a few hacks. First you need to run through the install by entering a domain account at the point where it asks for "an account to run the service under". The wizard will be happy with a domain account from the DEV domain and complete. The domain account is one from the Dev domain and there is no equivalent in the main domain.
At this point you are left with an error in the eventlog stating "You are not authorized to access ...". Now the hacking begins. You have to go to the services console (start->run->services.msc) and manually change the "Log On As" account for the "Visual Studio TFS Build Service Host 2013" service to your shadow account (i.e. the local account that exists on both the build server and the TFS server with the same name and password). You will need to restart the service for it to take effect. This should stop the error from showing up in the eventlog.
Lastly, you can go to the TFS Administration Console and add an agent. And now you should be able to send builds it's way.
The reason you can not configure the account through TFS Administation Console is because it does not allow a local account to be specified at "Connect to TFS as". This of course makes sense since normally a local account is not recognized outside of the box. The checkbox of "Use the same identity as Windows Service" is checked by default so it will use whatever account was specified as the "log on as service" account.
I hope this saves someone out there some serious head scratching.