The way I ended up doing the scaling (we didn't need any other format conversions) was using the retrieval URL and a 404 handler that is smart enough to be able to access a list of 'allowed' sizes (so that doesn't become a potential attack vector). So if you access a file in a size that hasn't been made yet it gets created on the fly.
The whole thing has been up and running across 9 servers for a year now, it has triple replication and a bunch of varnish servers on the front end to make it fast.
We have two ways of putting data on there, one through an API that accesses the servers directly, another using a queuing mechanism.
To improve the legibility of the urls we used a virtual path rather than a bunch of parameters.
so http://mycdn.com/storage/client/format/id/id/id/id/id/id/id....
where the 'id' bits are 2 digits from the image identifier.
The nodes have 4TB storage each. Originally we used XFS but deletion was too much of a bottle-neck so we ended up switching the system after it was already live to EXT3, which improved performance quite a bit.
I'm sure that if you build this 'properly' (as in nicely abstracted, multi-user, with redundancy by using multiple locations and so on) that there is a market for it but I'm not sure how big that market would be.
So yes, this probably has legs.