This is a good idea, if done carefully. I really dislike giving miners any decision-making power, for the reasons you mentioned and also because they are employees of the network -- the only parties paid by the Bitcoin system. I proposed similarly forcing the P2SH softfork when miners were (for a time) blocking that softfork, though miners stopped blocking it before too long.

This has the potential to get messy, though. Without miners, you have to be really sure that a large majority of the economy is going to enforce the new rules, since otherwise a prolonged split could develop. There's a worrying situation today where both mining and verification is centralized, even though Bitcoin really requires that at least one of them is decentralized. So there'd still be the ridiculous need to engage in lobbying, though in this case it'd be with big centralized verifiers like BitGo and bc.i rather than with centralized miners. (Verifiers are a lot less centralized than miners, though, which makes somewhat better.) If the softfork activates without a substantial majority of the economy enforcing it, then it could end up splitting the network/currency long-term, which would be the same sort of disaster as a contentious hardfork. There are a lot of economic reasons why this is an unlikely outcome, but it could happen if the softfork isn't done carefully. Before something like this is added for any particular softfork, I'd like to see a detailed investigation into how much of the economy is committing to support it; how much is actually doing verification rather than just blindly trusting miners; the popularity and expected behavior of each end-user wallet software; etc.

Another consideration is that if miners are expected to keep producing very long invalid chains under the new rules, then this sort of softfork has almost exactly the same costs as a hardfork. So if this is considered a likely outcome, then it'd may be better to just hardfork and make some other useful hardfork changes at the same time.

The flag day would probably need to be at least 1 year in the future to be reasonably safe. 2 years would be better. Backports would be needed for all versions that are actually being used, including the #bitcoin-assets 0.3.x version. I wonder if there's any reasonable way to handle the (hopefully very unlikely) scenario where a softfork needs to be canceled partway into the wait time.