Later on, we can use the usual mechanism for phasing in rule changes - have new block or transaction version numbers express acceptance of the new rule set and automatically begin enforcing them if/when more than a certain percentage of users have opted in (probably a very high percentage).
That's a terrible way of deciding an important issue such as this. Miners are not a very important part of the Bitcoin economy, and they don't have much more understanding of Bitcoin than anyone else. Their "votes" shouldn't matter more than anyone else's. (There shouldn't be general voting at all, in fact -- democracy is a poor way of making decisions.)
restricting the block size in the long term for the exclusive purpose of keeping transaction fees high is a form of central planning. If artificially restricting supply in order to manipulate prices worked to create a healthy economy, there wouldn't be so many people trying to leave managed economies for Bitcoin.
The block size limit doesn't need to be centrally-determined. Each node could automatically set its max block size to a calculated value based on disk space and bandwidth: "I have 100 GB disk space available, 10 MB per 10 minutes download speed and 1 MB per 10 minutes upload speed, so I'll stop relaying blocks [discouraging them] if they're near 1/8 MB [enough for each peer] and stop accepting them at all if they're over 2MB because I'd run out of disk space in less than a year at that rate". If Bitcoin ends up rejecting a long chain due to its max block size, it can ask the user whether he wants to switch to a lightweight mode.
Users could also specify target difficulty levels that they'd like the network to have and reduce their max block size when the network's actual difficulty level drops below that. A default target difficulty level could maybe be calculated based on how fast the user's computer is -- as users' computers get faster, you'd expect mining to also get faster.