I believe this is a bug with cleaning up an old SVM DR relationship. I don't know if NetApp has a fix in a newer version or not.
While probably not officially supported by NetApp, I've found a workaround.
cluster::> set d
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
Find the UUID of the vserver where the rogue snapmirror policy lives:
cluster::*> debug smdb table vserver_by_uuid show -vserver vserver1
This will spit out a bunch of stuff but you are only interested in the first field, the UUID. It will look something like: 63cd8266-f743-11e3-813a-123478563412
Delete the rogue entry out of the underlying table. Be very careful about this because if you delete the wrong thing it can cause all kinds of problems.
cluster::*> debug smdb table snapmirror_policy delete -vserverUuid 63cd8266-f743-11e3-813a-123478563412 -policy VserverDR
Once this is gone you should be able to go ahead and delete your old vserver.