Since the blocksize issue is controversial and may take some time to settle, we are better off implementing this elastic cap right now with a softfork (your phase II) and skip the hardfork part (phase I).
We could do that by choosing T=0.5MB (2T = 1MB = current maxblocksize).
True, if the circumstances were different. Presently the average (7-day, moving) block size (ABS) is about 400KB, 80% of T, and T will certainly be less than the ABS by the time an elastic cap can be implemented. ABS will never approach 2T because some miners will always churn out small or empty blocks (certainly while the reward > block fees), so the present ABS is for practical purposes equivalent to T now. The point which would normally be an alert for attention to be given to the prevailing limit.
The elastic cap with fee pool does need working out in detail, as the discussion between molecular and NewLiberty shows. Its mechanics, incentives, attack vectors and long-term implications need to be known and understood. This won't happen quickly. Phase I buys time for Phase II.
Increasing the 1MB is technically very simple, accepting just the usual risk inherent in larger blocks.
If this type of consensus can be hand-waved away, then we are going to have to go home and learn to love our respective fiats, because they will all be around for a lot longer.