First of all: I'm using CentOS 6 and keepalived 1.2.7 (02/21,2013)
I tried nopreempt as well and after some testing it works as expected.
Running master and backup with the same vrrp priority is abad idea because there is a bug (AFAICT) which leads to a situaltion were both keepalived server start the VIP.
according to https://www.rfc-editor.org/rfc/rfc5798#page-26 the keepalived with the highest IP should stay/become master.
I could not observe this behavior!
(AFAICT again) You have to remove the statement "state" from the config file if you intend to see nopreempt working.
If the keepalived with "state MASTER" in config file starts up it starts as master and advertises it self as such = bad.
If there is no "state" statement in the config file keepalived starts in state BACKUP and listens to vrrp. because of "nopreempt" it will not become MASTER even if it runs with highest priority. this is contrary to the man 5 keepalived.conf page, whereupon state does not matter much.
The keepalived with prio 255 always becomes master - regardless of nopreempt option on or off.
If you test keepalived have a close look at firewall/nat rules. it's always a good idea to run something like tcpdump to check if the vrrp advertisements get through and have the correct sender IP (the one from the other keepalived(s), not the standard gw!)
This is especially true if you use kvm/qemu guests as there are default nat rules which change vrrp advertisements.
nopreempt only works for keepalived in state BACKUP. (RTFM)
if keepalived (1.2.7) is running and the network link goes down keepalived changes to state FAULT. when network link comes back keepalived becomes MASTER if prio is high enough. I don't know if this is a bug but it makes nopreempt somehow useless. I'll send a question to the mailing list.
Have Fun!
Regards
Stefan Kärst