David,
Though we aren't using NFS we do have a BigIP directing IMAP and POP3 traffic to multiple dovecot stores. We use mysql authentication and the "proxy_maybe" option to keep users on the correct box. My tests using an external proxy box didn't significantly reduce the load on the stores compared to proxy_maybe. And you don't have to manage another box/config. Since you only need to keep users on the _same_ box and not the _correct_ box, if you're using mysql authentication you could hash the username or domain to a particular IP address:
SELECT CONCAT('192.168.1.', ORD(UPPER(SUBSTRING('%d', 1, 1))) AS host, 'Y' AS proxy_maybe, ...
Just assign IP addresses 192.168.1.48-90 to your dovecot servers. Shift the range by adding or subtracting to the ORD. A mysql function would likely work just as well. If a server goes down, move it's IP. You could probably make pairs with heartbeat or some monitoring software to do it automatically.
Timo posted a similar suggestion recently, and I might try to find some time to proof this out over the next few weeks. I liked his idea of storing the user's current server in the database and proxying to that, with fallback to a local connection if they're new or their current server is unavailable. The table cleanup and pool monitoring would probably be what I'd worry most about testing.
Unfortunately we're currently using LDAP auth via PAM... so even if I could get the SQL and monitoring issues resolved, I think I'd have a hard time convincing my peers that adding a SQL server as a single point of failure was a good idea. If it could be set up to just fall back to using a local connection in the event of a SQL server outage, that might help things a bit. Anyone know how that might work?
-Brad