Let's look at this a little more carefully.
Pretend for a moment that you operate a network "U". Pretend that someone else operates a network "E". Pretend that you share a downstream customer "C". So far, so good.
"C" has several different locations, none of which are directly interconnected. They advertise their aggregate netblock, which makes its way to the global table. They also advertise longer prefixes for you to deliver traffic to the specific location; these are tagged NO_REDISTRIBUTE.
This does not increase the size of the global table. This does not require proactive registration of an ASN for every potential customer, nor for every other transit provider in the world. It does not require a different ASN for each location "C" has. It does not effect any other number of wacky things that have been suggested.
It does require peering between "U" and "E", or de-aggregated prefixes to be leaked between the two. (Ask your transit provider; you're paying them for this service, so it makes them money.)
Now say that one person from each location sends in a monthly check for "their" portion of the service. Panic! Horror! Routing no longer works the same way!
Yes, aggregation means less flexibility. One therefore aggregates likes together. (Thanks David for the addressing/topology quote.) Some of you might even do this with your global announcements.
Must "C" renumber when changing providers? Yes. Sounds familiar.
I'm pointing out a way to give consumers dual-homing _today_, using installed technology.[*] I'm not claiming that it answers the question of portable /32s. I'm not saying that they'll be able to prepend AS_PATHs arbitrarily, send BGP communities, etc. -- and I'd even go so far as to claim they typically don't want to.
[*] Excepting CPE equipment, which would need a simple BGP speaker.