Honestly, I’d be really shocked if something like this is possible. The problem is two-fold:
First, the remote is looking for a signal from the z-wave device when it tries to setup as a secondary controller. Just like when you pair a device with the ST hub, you need to do some sort of physical action on the device to tell it to try to pair with a controller. I suppose it would be theoretically possible for the hub to emulate a z-wave node device temporarily in order to set this signal, but I don’t know for 100% sure if this is possible.
Second, once you have this pairing setup, any commands being sent from the remote are going to be sent out as a controller trying to talk to a end device, not as a controller trying to talk to another controller. In otherwords, if the Hub is in it’s default ‘controller’ mode, it simply won’t listen to zwave broadcasts from another controller. And obviously it the Hub is in this hypothetical ‘end device’ mode theorized above, it wouldn’t be able to listen for activity from other devices on the network that are trying to talk to a controller.
So the Hub would either be acting like a end device, at which point it would be completely useless as there would be no communication from other devices, or it’s acting as a controller, in which case your remote can’t see/talk to that virtual device you tried to pair it with.
Possible theoretical solutions might be to have a hub with dual zwave radios… one is ‘controller mode’, one is ‘device’ mode. The problem here is I don’t know if one zwave radio can act as multiple virtual devices… so you might end up needing one radio for EACH virtual device. If that’s the case then it’s going to get expensive fast! Even adding one more zwave radio might be more expensive (given the software and hardware behind the scenes needed to support this) then just buying a cheap z-wave outlet, putting it somewhere that it will never get used and using it as a real world virtual device.
The other possibility is developing the firmware so that the hub switches rapidly between controller and (the hypothetical) device mode. But I really worry that there might be major communication issues with this idea.