I assume that your AT&T MPLS is like ours. You aren't "really" participating in the MPLS network. You just have an IP connection to AT&T and a bgp peering arrangement over that IP connection. The fact that AT&T is using MPLS internally is transparent to you.
In that case, I don't believe that it can be done, short of some approach such as tunnelling or segregating your network into multiple VRFs each with its own connection to AT&T. (We use both of those approaches on our AT&T MPLS network, though not for the purposes of Internet load sharing which you seem to be after).
In the frame relay world, you were handing off frame-relay frames to the carrier. They were routing those frames based on DLCI. So at each of your source sites where you were injecting traffic into the carrier's cloud you were in a position to choose the egress site where that traffic would emerge from the cloud.
In the AT&T MPLS world, you are handing off IP frames to AT&T. They are routing those frames based on destination IP address. You are not in a position to do source-specific routing. AT&T will route toward each destination IP address based on its internal routing policies.
AT&T's internal routing tables are constructed based on the routes you advertise to AT&T. However, unless I'm missing something, if you advertise three default routes into AT&T and tag them, AT&T will ignore those tags when constructing its own internal routing tables for your traffic. Perhaps you could work directly with AT&T on this.
At the far end, your bgp process will listen to AT&T and see the three default routes. And it can select one of the three based on your administrative policy. But all three routes have the same next-hop gateway -- that site's AT&T peer.
No clever bgp tactics are going to do you any good.
At the destination site, you need to advertise the route to AT&T and they need to see it -- else they can't route the traffic.
At the source site you have no choices. You need to route the traffic to AT&T.
What you _can_ do is to create tunnels over the MPLS WAN. And you could choose to default-route your traffic over the tunnel of your choice. That puts you back in control of the egress site at the far side of the cloud. Of course, you'd need to be prepared to deal with the resulting MTU issues if you choose to take this approach.
I was hoping that even though using BGP to route to ATT MPLS network could deploy eBGP multi-hop between the far end BGP peers with tagged traffic and some route map and/or ACL to only route by that advertised route for the default route and hoping since that tagged BGP routes are between the far end eBGP AS peering ATT would not even do anything with that traffic and would just be using iBGP bettwen our and ATT routers.
I am going to get in touch with some of the ATT engineers to discuss soon, will find out then what can be done.