It is not possible to have a “centralized” VRRP, but you can use one VRRP as a controlling one for all the other ones by means of scripts associated to state changes that change the priority of the other ones. Or even a more complex setup (if any of the interfaces that should be in backup mode when everything works changes state to master, it adjusts the priorities of all the other ones to become masters as well) is possible, but it is very easy to get lost. So it is much better to have an interconnection network between the routers so that the VRRP state at WAN side could be independent from the VRRP state at LAN side. But a lot depends on the physical topology of your network, in many networks there are multiple LANs and routing among them needs to be provided too. E.g. in your case, the Wireguard client subnet is effectively another LAN.
So when I do this type of setup, I use /32 addresses in an auxiliary subnet for the VRRP protocol itself, and assign the virtual address with a shorter mask, so the connected subnet is only active at the router that is a VRRP master, and propagated from there using OSPF to the other router. The wireguard interface, however, stays up all the time no matter how many clients are connected to it, so you’d have to use the script attached to the VRRP WAN interface to enable and disable the wireguard interface in order to let it be propagated only from the router that is a VRRP master on WAN.
There is also the completely different approach where VRRP is only used as a means to let both routers know about each other’s state.