Heartbeat Options with MySQL and Possibilities
The make-or-break element you should be concerned with is Replication Lag. Why ?
If you run SHOW SLAVE STATUS\G and Seconds_Behind_Master on the Slave is significantly high, failing over to such a Slave could be disastrous. Think of it:
If a Slave is 60 seconds behind, there is a 60 second window where

primary keys you need do not exist
changed column values do not yet exist
rows that should exist are not present
rows that should be deleted are still present

just to name a few possibilities.
SUGGESTION
Right after you've checked that the Master is fully down, you then need to check the Slave by running SHOW SLAVE STATUS\G to look for the following:

if Slave_IO_Running is not Yes
if Slave_SQL_Running is Yes
if Relay_Log_Space stops changing (This indicates that there are no more binlog entries coming over from the Master)
if Exec_Master_Log_Pos stops changing (This indicates that all relay log entries have been processed)

Once these four criteria have been met, the DB VIP can be assumed by the Slave.
CAVEAT
You may need to look into using MySQL with DRBD
Please read some of my earlier MySQL/DRBD posts:

Dec 26, 2012 : MySQL Replication and High Availability
Oct 17, 2012 : Setting up DRBD on an active MySQL server
Mar 29, 2011 : MySQL high availability, failover and replication with Latency

I suggest DRBD because the Slave is Replicating at the Disk Level synchronously.
A failover would just need DRBD mounting and InnoDB Crash Recovery on MySQL Startup.