Hey LenK,
You didn't specify how you are hiding (or otherwise abstracting) the IaaS Blueprints in the 6.x environment. I am making the assumption that you are using the Services hack? (Entitle a deactivated service to the business group)
In any case, I will share with you my alternative method and why I believe I will have success moving it forward into 7.x: with this caveat. I have not played around with 7.x since the Beta, and I had certain verbal assurances from product management on the entitlement capabilities that may or may not impact this practice. If an option wasn't retained in entitlements for a "support" person to be able to run resource actions on machines, even when they cannot see/provision from the blueprint the machine is tied to, this will not work.
GENERAL TOPOLOGY ASSUMPTIONS
1. Multiple Entitlements can still be used against a single business group with each entitlement having the ability to see "different" services, catalog items, and resource actions.
2. Provisioned machines are "owned" and there remains methodologies for ownership to be changed. (e.g. through Reconfigure resource action)
3. Business Group users retain the ability to be able to see Resource Actions for machines attached to Blueprints that they are not entitled to see.
THEORY
When we take those assumptions, consider in a (6.x) business group that I would be able to provision a machine through an IaaS Blueprint Catalog Request that you cannot see. But you can own the machine after I give it to you. A service account can act like me in that regard. (request you a machine from something you cannot see and then give you ownership of that machine)
EXECUTION
I am going to use this workflow to explain. In this case, this allows for the building of any published/entitled IaaS blueprint in any business group from a single ASD request form. (not your exact use case, but read on... it ties) We entitle the ASD form attached to this workflow to our engineering support team so they can push machines out anywhere to any owner (found in the selected business group). In any Business Group, they cannot see the 40 or so IaaS Blueprints that they can build using this form. These IaaS Blueprints (catalog requests) are grouped by a Service (called ASD Blueprints) and we maintain a specific entitlement in every business group for our Service Account. (I automated all business group and entitlement work through ASD forms, so it isn't as daunting as it may seem.) The Service Account can see the ASD Blueprints service through that entitlement.
#1 Dynamic inputs that include looking up various IaaS Blueprints (in the ASD Blueprints Service) based on entry selections. Like if Windows is picked, only the Windows Blueprints are returned to the requestor.
#2 Arguments taken from the form are translated into a Cloud Client friendly string.
#3 The string (to include IaaS Blueprint) is fed into a Cloud Client request on an SSH script host. The request is made as the Service Account because it is the only thing that can actually see the blueprints.
#4 When you make a catalog request in Cloud Client, you get back a request id. This workflow just iterates the actual request and waits for request completion (or a timeout). It returns information that can be sent back into the original request. (throw REAL designed-smart-errors visible in the original vRA request)
#5 We allow our Engineering teams to select an owner from those in the Business Group. If that was done then the owner is changed. (Keep in mind... they could call themselves as the owner. This means they had the means to request a machine in their own business group, through an ASD form... against IaaS blueprints that they couldn't see. You would have to connect the dots as to how this would need to change for you to automatically take requestor as an owner.)
#6 Service Account owns the machine in the business group. But we wrote a Change Owner resource action (the one called in #5) and so the owner can be changed as a Day2 operation at any time. Plus at the business group level, we tag a custom property for the Business Group manager, email, etc which are stamped on built machines... and this gets us around single owner reporting and management issues, inherent in the self-service tunnel vision of the current product.
So when our automation processes create business groups, several entitlements get laid down. The top one is the Base Business Group entitlement. It can see core Services for the Business Group... duplicated across all business groups. Our general service offering. There is also an optional add-in Service for dedicated catalog items. The next 4 are all support entitlements. They hold various capabilities (resource actions primarily) against provisioned resources. The final is the Service Account. It can see everything in every business group. It can also see all the ASD abstracted BluePrints through the ASD Blueprints Service.
So if we give the Base Entitlement the ability to request a RHEL7 ASD Service Blueprint, the workflow on the back end can use the Service Account in this Business Group to build the IaaS machine based on the request and then change the owner to the original requestor. This doesn't have to be done using cloud client. We used to use Request a Catalog Item.
RISK
If the product team didn't take my advice in the early Beta and keep an ability for a person who cannot see an IaaS Blueprint to be able to run Resource Actions on a machine provisioned from it... then there probably won't be a way to create ASD wrappers with hidden IaaS Blueprints. I am told that my request made it into the product. Those who have deployed vRA7 would need to validate. Basically, you should be able to make an entitlement that both hides a catalog item but allows for resource actions on that catalog item. (we were talking at one point about a checkbox in the entitlement or something to that effect. I don't know how they ended up implementing it.)