To answer your 2nd question first, AFAIK, this is not a current built-in feature in the BIG-IP.
If it OK for a request to go to a different server during heavy load, then why do you need persistence? Clearly if the content available on different servers is equal, then persistence is not necessary.
You didn't mention what sort of persistence you are using and that may make a difference to the answer.
Figuring out the amount of calls to a specific server at a given time is tricky business - especially given the fact that most new platforms have more than one TMM running on the box.
I could see using the "table" command to keep counters and increment/decrement them appropriately.
Now, when the amount connections to a particular pool member reaches an appropriate threshold, you can do a "persist delete" (if using source persistence - for example) or do a HTTP::header delete (if using cookie persistence). This is followed by a LB::reselect to select a different pool member. Of course you now have to add protections to prevent the other pool members from getting saturated.
As you can see, this iRule may start getting complex fast.
Another solution you may want to consider is the use of "priority groups" on pool members in conjunction with "connection limits". There is a pool member setting that lets you control what to do with "persist connections" if a pool member is already at the configured limit.
Nimbostratus