Certainly, a dynamic means of adjusting the block size which could not be gamed by miners would be great. Linked by Peter was an idea from Gavin of determining an appropriate block size by the times taken by nodes to verify blocks.
Unfortunately, I'm not aware of any proposal which really does this. I don't know the precise details of your proposal and currently don't see how you intend to guard against large miners simply creating millions of transactions to trick the dynamic algorithm into thinking that very large blocks are needed.
My aim is a broad call for a (re)consideration of a dynamic "demand-driven" block size limit mechanism. The best adjustment estimators have yet to be determined. I think the concept should not be prematurely dismissed, because it could be highly beneficial in terms of resource preservation and hence decentralization.
The problem that selfish large miners create millions of transactions could be alleviated by using a median (instead of a mean) statistic in the adjustment estimation, which is much less susceptible to extreme values. Maybe one could also do statistical correction based on IP adresses (those that frequently submit only blocks with a excessively huge number of transactions get less weight).
I'd better say: "Only raise block size limit if required by the minimum amount necessary."
What constitutes "necessary"? What if there are so many "necessary" transactions that it's impossible for Bitcoin to continue as a decentralised system? I'd like to see as much block space as possible but will happily work to keep the blocksize smaller than many deem "necessary" to avoid centralisation.
Of course "necessary" has to be defined. I think it is acceptable to make Bitcoin progressively more unviable (through higher fees) for microtransactions if decentralization is at risk. Very small transactions could also happen off-the-chain. However what "small" means is open to debate.