Good news: After all the posts here and several vmware tickets we did wind up getting that distributed lab of vRA 6.2 build. 
Have a ticket open on this situation but thought I'd also bounce it off people here to see if you've done something similar.
Situation: Our distributed install uses the vRA Identity Appliance. The hostname is the FQDN of the appliance and that FQDN is also the SSO Host listed on the two vRA Virtual Appliances. This works as expected from an administrative jump-host. You hit the URL of the tenant (which uses the vip\pool dns name), it takes you to the SSO fqdn, you log in, your URL bar is back to the the vip\pool of the Virtual Appliances). Network Security has not opened 7444 directly to the Identity Appliance from the general user block (stating security concerns having users connect directly to the SSO server, understandable). Instead a VIP rule was created (on the same vip\pool dns name as our Virtual Appliances) to forward traffic over to 7444 on the Identity Appliance. No config changes on our appliances so as expected from the user block one cannot get to the vRA portal because they can't hit SSO.
Query: We had a weird issue in our 6.1 non-distributed lab where vSphere SSO was rebuilt and wound having to rebuild all of 6.1 to get connected back (quirk, who knows) so we are hesitant to go and just update the SSO Host setting on the 6.2 Virtual Appliances. Presuming it works we'd also need to change the Identity Appliance certificate to include the additional name in the SAN (Network Security did say they are not tied to using the same dns name we have for our Virtual Appliance pool and just want it to be not the real fqdn of the appliance...right now it just seems odd to try and put the same name in for Host Name and SSO Host on those virtual appliances despite the VIP rules). Has anyone else set up their vRA SSO Host as something other than the fqdn of the SSO server (specifically Identity Appliance in our case but vSphere SSO as well)? Basically just wondering (a) if it would function in an already built environment and (b) if it would work for an environment being built so we can just start out with an alias\VIP name when we build our prod vRA. Like I said the whole issue we had in our non-distributed has me leery of just experimenting and hoping worst case it will just take the original setting and carry on happily.
Edited to add: So basically like how in "Configuring VMware® vCenter SSO High Availability for VMware vRealize Automation: Deployment Guide for High-Availability Configurations: Version 6.1 and Later" on page 44 "Configure vRA to Use vCenter SSO and you put the FQDN of the load balancer name for SSO Host can you do something similar [ie a load balancer name that behind it is an Identity Appliance and not HA vSphere SSO] and do it after the whole environment is already built out. It *sounds* pretty straight forward but then again with this thing I am very over making any assumptions. :smileylaugh: Would also presume on the Identity Appliance at the least a cert update would be needed on the SSL tab, not 100% on updating its Host Name setting to the load balancer name.
