Wow, what a setup. This is not an answer, just a suggestion and more questions...
I've included two links to documents that I don't know if you've read or not but they should help with figuring out bandwidth usage for those remote sites and whether you need a Distributed Repository (DR) or not depending on how many systems you actually have in those environments.
If there are only 10 to 50 nodes, you might not need to use a repository because that would actually take more bandwidth depending on what the DR is storing and how often you decide to make changes to your software versions or policies.
The agents must be able to contact the main ePO server. The ePO server tells the DR to install a specified product which takes the load off the ePO so it needs to be able to communicate with the ePO. The only other way to make this work is to deploy an ePO in each remote VLAN which doesn't fit into your plans.
Even if you setup the DR, how do you expect the DR to contact the HQ ePO server to get the updates? That is a lot of configuring, good luck!!!
At 10 to 50 Nodes per site it is my experience you will not need remote repositories. Unless the links a very slow (256MB or less). I use Super Agent repositories with the Lazy Caching turned on. All my network bandwidth issues went away. No more pushing 100MB every night. Nothing to manage or worry about.
For DAT and other content update you need lots more than 50 nodes to worry about nightly bandwidth issues for normal updates.
The only time having remote repositories really helps is during product updates. Or new builds with VSE needing the 100MB original DAT file.
You can deploy the Management Agent (framepkg.exe) from within ePO. You will need an account that has Administrator Privledges on the target machine. You can manually do by selecting the machine in ePO. Or as I have done set up a nightly server task. It runs a report that finds all machine that report no ePO client, and then deploys the agent to them. We get all new machines into ePO by a sync with AD.