As of current, Wireguard listens on all the addresses of the router and the VRRP ones are no exception; what may require some additional measures is that it would use the VRRP address as the source one of the packets it sends. To ensure that, it may be necessary to use techniques similar to one of those described in this post and a few subsequent ones.
Now followup question: If a router which is VRRP slave receives a packet for the VRRP address, would it be forwarded to the VRRP master?
Or, would a slave VRRP just not listen on this address? Then, what happens if a VRRP master listens on, say, 51820 and it transitions from master to slave?
The principle of VRRP operation is that the address is up only on the current master. The current master responds with the virtual MAC address to incoming ARP requests regarding the virtual IP address, and sends frames with that virtual MAC address as source.
Therefore, a packet for a VRRP IP address normally cannot reach the routers that are currently slaves for that address, as due to the above, the switches send the incoming traffic only to the current master (this is different from other redundancy mechanisms where the virtual IP address uses a multicast MAC address and that MAC address is never used as a source one). But even if the packets made it somehow to a slave, it would ignore them as the IP address is only activated on the current master.
If a master fails and another router becomes a master after a short while, the traffic for the virtual address starts arriving to the new master immediately; what the Wireguard stack running there does with its is another question. I am not a huge fan of Wireguard so I am not sure here, but my assumption is that the tunnel connection may stay down until a new handshake takes place within about 2 minutes.
It is possible to implement VRRP between two WireGuard servers. It requires a few configuration steps that might not be immediately obvious, but yes — it works, and failover is extremely fast.
In my setup, I have only one public IP address, which terminates on a main firewall. Behind that firewall, I run two CHR MikroTik routers with VRRP configured on private IPs. The main firewall performs a DST-NAT to the VRRP virtual IP, which then forwards traffic to the active WireGuard server.
No client-side changes are required, the redundancy is handled entirely on the server side.
I ran into the issue of Wireguard answering and creating the tunnel from the interface IP address, not the VRRP address, which breaks the redundancy as my Wireguard client will only keep trying the router's interface address, not the VRRP address.
What I ended up doing is adding the VRRP IP address as the pref-src on my default route. So far it's working in testing. The client connects to the VRRP IP, establishes the tunnel on that IP, and if the primary router goes down and the backup takes over, my client reconnects within 3 minutes.