Well, distributing the verification "back" would be nice, but it seems to me (from your post and elsewhere) that there are practical issues with that (and little to no impetus for pools AND for-profit miners* to adopt such a technology).
I don't think they are necessarily insurmountable, but yeah, missing data is hard to handle.
Personally, I think adoption / social issues may turn out to be worse than technical ones (though the latter have not been surmounted yet, either).
Your typical pool, and your typical for-profit miners don't give a single rat's ass about decentralization or whatever. They're in it for the money, which isn't necessarily a bad thing, but could easily lead to a kind of "tragedy of the commons" scenario.
If a transaction 20k blocks before the end of chain goes missing, does that invalidate the chain?
I'm not really the To Go Guy in this regards, but it seems to me that for various "distributed work generation" systems to work, pool's clients must be kept aware about all the transactions that need to go into the block OR ELSE.
You simply cannot make an algorithm that is, in general, resistant to ASICs. If a general purpose CPU can do it, then a purpose-built CPU can do it faster.
While probably true in general sense and almost certainly true in the "efficiency" ("performance/J") sense, I am not convinced that the difference between ASIC and CPU can not be made to be rather unimpressive by clever algo design. There's clearly not enough work in this are, however.
Also, if you, at the very least, can drive ASIC development and manufacture costs high enough (which isn't impossible), you can render any ASIC operation economically unsound.
P.S.:
If we're talking an economically irrational opponent with virtually unlimited funds, then ASIC resistance, theoretical or otherwise, becomes irrelevant.
Such an opponent would buy up whatever equipment he needs to dominate your chain, be it CPU rigs, ASICs, or goddamn Blue Gene.