I’m not sure the treatment of DHCP packets on a VLAN-enabled bridge is any more useful than matching by IP address in bridge filter rules, you have to try - the manual is silent about that.
The way you put it, an “anycast gateway address” seems to me the best approach to fit your needs. In short, devices on all sites would be told to use the same IP address as a default gateway, yet on each site that address would be translated to a MAC address accessible only on that site. This can be achieved using multiple ways, but to me, the most manageable one (because the settings are identical on all sites) seems to be to add a VRRP interface to the VLAN interface where the actual address of each router for that subnet is attached, and attach the anycast gateway address (like 192.168.88.1) to it. But to serve the purpose, you have to use rules in chain input of ip firewall filter to drop received VRRP protocol messages from other sites on each router, so that all the VRRP interfaces would stay in master mode, and on the bridge filter, drop frames with dst-mac-address=00:00:5e:00:00:00/FF:FF:FF:00:00:00 in forward. So the clients in that subnet will send an ARP request for the gateway IP address, get the VRRP MAC address in response, and send frames carrying the IP packets that need to be routed to that MAC address; since the bridge forward drops frames for that MAC address, only the local router will receive them.
This approach addresses routing to the internet; inter-VLAN routing will end up non-symmetrical because if two VLANs are bridged among multiple sites, the packet from site A subnet X to site B subnet Y will be routed from subnet X to subnet Y by router A but the response packet from site B subnet Y to subnet X will be routed by router B. So the stateful firewall on each router will only see one direction of the connection and behave accordingly (block some connections, use different timeouts for others).
How much of an issue the above is in your use case? Do you need inter-VLAN routing at all?
Not sure whether OSPF could take care of this at all, but as a minimum, all the endpoint devices would have to support OSPF, as the ICMP redirection is used to tell the endpoint devices to use another gateway. Normally, only routers use OSPF to inform each other about destinations they can handle.
This topic is actually a bit of a gray zone - the RFC regarding VXLANs suggests that VXLANs should drop VLAN tagged frames (whereas Mikrotik currently lets them get through), but it also doesn’t anticipate any handling for STP BPDUs because it uses its own mechanisms to prevent L2 loops. So it assumes VXLANs to completely replace VLANs and the L3 redundancy mechanisms used to route the VXLAN transport packets to prevent occurrence of loops in the L2 payload domain rather than STP. So on each datacenter host, each VXLAN is presented as a whole VLAN-agnostic bridge rather than just a single port of a bridge, i.e. the virtual network interfaces of the virtual machines are linked directly to the VXLAN rather than to an intermediate bridge. And to cause an L2 loop, a VM would have to internally bridge two network interfaces connected to the same VXLAN, which is far less likely than plugging a patchcord to a wrong port in the physical world.
So a “future-proof” (as in “change of mind on Mikrotik side - proof”) way of mimicking this on Mikrotik would actually be to go back to one VXLAN per VLAN approach but force the VXLAN ports of the local bridge to be edge ones and let the bridge filter drop BPDUs (dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF) received via these ports.
