20% time is alive and well, but you have to be careful when thinking that 20% time is going to magically result in fully-polished new products. How much code can you write in one day a week? How much legacy code can you maintain in one day a week? The fact that programming is hard puts an upper bound on what you can effectively accomplish in your 20% time.

Effective 20% projects, in my opinion, are projects that add something new to an existing product and whose maintenance costs are low enough to be absorbed by the project's primary contributors. I've been working on Android lint checks recently: it's something that's self-contained, can be done without interfering with my 80% project, and won't make extra work for the project's main maintainers. (It's also open source, so it can't be canceled. Hah!)

It's also worth pointing out that not all 20% projects at Google are going to be visible outside of Google. I spent my first couple quarters at Google working on maintaining the internal Emacs extensions and user-base; most of my time was spent answering questions on the mailing list. This isn't going to result in Google Maps or Gmail, but it is still needs to be done.

If you want to do something with more public impact, I think you should work towards making that idea your 80% project. Get buy-in from your peers, write a design doc or description of the product, and talk to people who work on similar projects. Once you have a team ready to work on the project, a good design, and clear criteria for success, it shouldn't be hard to become a "real" project.

(I've succeeded in doing this for an internal utility I wanted to write. I wrote a design doc, got some feedback from my peers, and asked my manager for a quarter to work on it, and did. Now it exists and has users!)