You certainly can feel superproductive working on greenfield projects and, once in a while, actually be superproductive.
I've found that the skills of a maintenance programmer are sufficient to punch my meal ticket. Early in my first W-2 job after grad school I took pride in my ability to pick up any tools and solve any problem with any system. Since then I've never been unemployed more than 2 days.
Since then I've fixed linux kernel bugs and built Silverlight applications with Visual Studio. (Ok, I have taken "Cold Fusion" off my resume.)
From time to time I have gotten into conflicts with management that it takes too long to do things -- but between learning new environments and understanding new systems, maintenance work is slow.
One critical skill is understanding a system enough to make surgical changes. Many people look at an old system and they want to tear it up completely and rebuild it -- often they think they can do this quickly, but often they understand at most 10% of the functionality of the real system. Other people, pressured by their boss, make a quick patch (that's not so quick) that ends up breaking other things. The work of understanding the code so you can make a small change takes a while -- yet, I think it saves time in the long term because it's better to spend 3X the time to get a 95% chance of success than to plan something half baked in X time that has a 25% chance of success and blow the schedule by repeating that mistake repeatedly.
Greenfield development is risky, making it harder to get a good a job doing it.
To take an example I spent much of the last six months building a beautiful system from scratch on my own dime.
Within two days of hearing about it, one of the largest companies on the internet made a concious decision to put me out of business. Tough luck, but any entrepreneur faces the risk they'll "build it" and nobody comes.
Another issue is that many "productive" greenfield projects are done by a junior programmer who is really proud of what they pass over to somebody like me to send into deployment.
Frequently these systems are full of bugs and come nowhere near meeting requirements -- hopefully you find out that the app malfunctions when somebody puts a single quote into an HTML field before it goes into production. Less than 50% of the effort has been done, but somewhere some smug opinionated programmer thinks he's the man.
All over the world, however, there are companies that have an existing system which is (i) critical to business goals and/or (ii) a source of revenue that they are not in complete control of. They need a professional programmer who's going to deal with the code in front of them and they'll pay for him. Yes there's a certain kind of stress that comes with this work, but that's the way it is.