Any reason why the following won't work? It sounds too "easy"...
Server A is the primary DNS for a domain, and hosts its website, its database, and its email (SMTP in, dropped to POP3 mailboxes via spamassassin). All relevant records are in the DNS: www., pop3., etc, and point to Server A.
Server B is the secondary DNS for a domain, but all the records (www./pop3./etc) point to Server B (not A). Server B has an exact copy of the website, the database (synchronised through MySQL replication), and drops any email it receives through its own spamassassin into its local POP3 mailboxes.
Server A also uses fetchmail to collect mail from Server B and drop it into its local POP3 boxes, in case any arrives there.
TTL on DNS records on both servers is set to a short period (say 15 mins).
In normal use, the domain resolves to server A and server B just acts as a redundant backup. If/when server A fails, its DNS vanishes and so clients request from the DNS on server B, which directs them to the website and database on server B and drops email into its local POP3 mailboxes. (The end user, when checking their email, will likewise get Server B when they query pop3.theirdomain and start collecting email from Server B.)
When server A recovers, things go back to normal, with any remaining mail in the POP3 mailboxes on Server B pulled over by fetchmail.
Server A and B will be in entirely different locations (maybe not even on the same continent!)
The only obvious problem which comes to mind is that writes to the database on Server B will get the databases out of sync, therefore I'd make remove write access to the databases from the website and modify the website code to handle that.
In case anyone ends up at server B when server A is up and running, it could be told to connect remotely to the database on server A unless it can't, falling back to database B. In this scenario session handling would be messed up unless the session info is stored in the database and sync'd across.
NB: From experience a lot of spam follows the lower priority MX in case it bypasses the spam checker, which would put a lot of the spam load onto the redundant server, hopefully allowing legitimate email through more quickly.