I've seen several topics about using two pi-holes to serve up DHCP replies and the suggestions for getting them to work together without conflict. None of them seem really optimal to me but they are workable. Given that, look at this as more of a discussion starter than an actual request someone start writing code.
Looking at the ISC DHCP server, it offers a failover option that looks interesting, particularly the problem section. Getting something similar in Dnsmasq is not likely but possibly something to accomplish some of the functionality could be added to the pi-hole software, not modifying Dnsmasq code.
A simple first thought is to have a primary and fallback DHCP option/setting for pi-hole that picks the type of DHCP service that that pi-hole will provide.
The primary would work just as the current setup does.
The fallback would normally be disabled to avoid conflicts. A daemon or cron job could check the availability of the primary DHCP server and if it appears dead could enable the fallback DHCP server and disable it if the primary again appears to be working. The primary "server down" checks would not need to be frequent given the DHCP renewal process but primary "server up" checks should probably be much more frequent to keep from having the two servers running at the same time.
Both could offer the same pool of addresses, not trying to manage duplicates, instead depending on the client performing an ARP check to make sure the address is not being used by another client and reporting any conflicts back to the server.
Not forcing a client to change IP addresses to ones in a different IP pool avoids the issues mentioned at the ISC link.
If that proves workable then possibly the teleporter code could be leveraged to insure the settings between the two stayed in sync? Possibly even disabling user input on the fallback server and only populating from the primary.
If someone wants to experiment using just the cron start/stop options it appears that the webpage script offers a DHCP enable/disable command.