Reguardless if its suppported or not, I have been successful with a couple different customers and pointing a RAP to a VRRP address for controller registration. When VRRP fails over, the RAP will have to register to the other controller which is not typically a huge issue. LMS/BKup-LMS will trigger a bootstrap as well.
There are a couple different ways RAP's can use be used with redundancy. Either option requires them to bootstrap when they failover. You do need to remember that the biggest challenge is when the RAP discovers the controller its hard coded and that can be fqdn or IP. I perosnally like to set the VRRP as the master discovery, as this way the RAP will boot, download its config, reguardless of which controller is active (both controllers must exist on same L2 segmant). There isn't any reason on why you cant test by using a VRRP on your single production controller, and open a firewall rule for 4500/udp. VRRP doesn't require a partner in order to become active. You could also go the opposite way if your setting up a local controller. Standby controllers cant register any AP's and you would have to failover the enviornment to test.
After config is downloaded the RAP will use LMS or Bkup-LMS depending on your config. If the controllers are in same datacenter and there isn't any internet redudnancy, it probably doesn't make sense to do 2 public IP's. If the controllers are in different data centers with different public IP's, then maybe its best to have lms and backup-lms. In the case of 2 data centers, maybe using a DNS entry for the master is best, as that can always be updated or applied as round robin for redundancy.
Biggest challenge with any remote worker is what happens if the vpn appliance goes down and is not in service. How can you dynamically get those devices to re-register. Upon registering to a controller the RAP will always download its latest config, and if the LMS changes and the RAP is registered it will be udpated and bootstrap to the new IP address.
As long as you create a new AP system profile and link that to a new AP-Group you shoudln't have any issues. Just keep in mind that references are used, and if the ap system profile your using in ap-group may or may not have LMS assigned. If there is no LMS it typically will use the master discovery IP. I have seen many customers update an ap system profile thinking it referenced only that ap-group, and they brought down the environment. (there is a "show reference" button, and i highly recommend to use it as much as you can).
The last I have to offer is about master-redundancy or master-local. Both methods will serve AP's just fine. It really comes down to personal preference and type of design your looking for. Most smaller deployemnts with 2 controllers typically use master-local, as it can be used in an active-active deployment; whereas master-redudnancy can only activate aps on master controller although there is always a mgmt plane to make config changes from.
Master-Reduancey = active-standby, and you can only register aps to the active controller. The role of the controller is triggered by VRRP failovers. Whats nice about this method is you always have a controller you can push config changes from. Make sure database sync is enabled.
Master-Local = active-active, and you can register aps to either controller. VRRP failover does not affect the redudancy model for controllers although could affect where AP's register. The local always obtains configs from master; and if master goes down you cant change anything on the WLAN until your master is back online.
hope this info helps!!