Messages

If you'd like to prefer one route over the other, what about a using route maps and set the local preference to meet your needs?

BTW regex based filtering/route manipulation is a common CCIE lab scenario, and the good old ^$ trick is a fantastic one to have in your locker (for any stub sites esp. EIGRP stub, filter outbound BGP via ^$ i.e. only allow local originated routes, its clean and no maintenance).

for the sake of redundancy, we don't want to filter out BGP routes learned on our MPLS head end routers. We'd like to prefer one path over another, and in the event of a failure, switch over to the alternate path as quickly as possible.

BGP != quick

Here's a thought:

• field site sends community ABC for subnets ABC to both MPLS providers
• field site sends community XYZ for subnets XYZ to both MPLS providers
• two MPLS routers back at datacenter, R1 peers with Provider 1 and R2 peers with Provider 2
• router 1 redistributes all Provider 1 BGP routes into EIGRP, but applies a nasty EIGRP metric to anything with community XYZ
• router 2 redistributes all BGP routes into EIGRP, but applies a nasty EIGRP metric to anything with community ABC

With some EIGRP manipulation at the site, you can ensure that subnets A, B, and C will traverse Provider 1 and all subnets X,Y, and Z will traverse Provider 2 when sending traffic to the datacenter.
Back in the datacenter, an aggregate router between routers 1 and 2 will make the final decision as to which provider to traverse to when sending traffic to the site.

In my experience with Verizon, L3 and CLink, none of them like to pass along communities.  They all strip them out in transit.  Thus far, we've not been successful at convincing any of them to cease so we are looking at alternatives. 

I'm more curious of what the end goal is, what are you trying to accomplish.  We were attempting the basically the same thing when we discovered the what the providers were doing...