A "solution" of this type would simply not be bitcoin. An ever increasing blockchain is an integral part of the system that you bought into. Any other solution is no longer the zero-trust system Satoshi invented and that we all bought into.
Further, you cannot handwave away the problem that, if transactions is infinitesimally cheap, people will abuse the system by sending non-currency data messages. Lots of them. Gigabytes worth, as other alt-chain field experience has proven. To the point that bitcoin-the-currency transactions are impacted.
"I want a system that can process infinite amounts of traffic" is in the land of unicorns.
The accusation of dev laziness is particularly rich, given that SatoshiDICE abused the blockchain in this way, by sending informational messages (IM "You lost a bet") via the blockchain.
If you want an infinite amount of transactions per 10 minutes, you have just reinvented the Internet... over the blockchain. Poorly.
All that said, block chain size has an easy solution for the individual user -- use an SPV wallet. And for the medium term, there are plans for distinguishing between archive nodes (those that store the full chain) and validating nodes (pruned).
The assumption that SatoshiDICE is 'abusing' the blockchain is patently false. It's a consent driven network - users should be able to use it in any way they like without artificial barriers like this being put in place.
As for handwaving (and unicorns) - There are solutions that would be possible given existing tech and being novel in it's application and methods.
If bitcoin goes this route it will doom itself to a series of hard forks followed by eventual regulation and failure. Instead of trying band-aid fixes lets actually address the problem which is (blockchain) size. How much of it would a client actually need to store? What about compressing the blockchain after the fact... simple groupings of balances by value as an index might help for starters. I really doubt we're storing it in the most effecient way possible.
Another thing is - once you've got the network agreeing on a truncated format for old (archived?) blocks - it's easy enough for someone to later use the dust - all that changes is that entry would be absent from the value index at the next demarkation.
So lets start thinking in terms abstracting the blocks in the chain once they get past a certian 'age' and actually develop a technical solution instead of heading down this road.