You can look at this as either a as time in limbo; or you can turn it into an opportunity to grow.

The core idea of being a maintenance developer is to put yourself out of a job. Each time you have to fix something; take the time to understand the problem well enough so that your solution (which could come a few weeks after you put out the fire) means you (nor any other living soul) will ever have to solve that problem again.

Since it's a legacy system you're supporting, you can usually get a way with some solutions that wouldn't be "ok" for mainline products; you can use cron to periodically restart buggy services; You can hard-code exceptional logic for particular customers since the number of customers using that product won't increase.

Another part of it is extracting useful knowledge out of the system; You probably don't want to do this, it's not very much fun; but by documenting what the working system does (even if it does it wrong), you can make the task of mantaining that portion of the application an order of magnitude easier (ten minutes to read two paragraphs that explain a module, instead of three days reading the module code). Better yet, this same documentation can be used to implement the functionality in the mainline product, so you can stop supporting the legacy system altogether (for that feature, at least).

If you're the "go to guy" for a project, even if that's legacy maintenance, you probably (or at very least, you should) have considerable latitude to approach problems in your own way. That might mean rewriting sections in your favorite language or platform, suggesting workarounds instead of solutions, or just responding to issues with "wont fix, use supported products".

Edit: You might be misinterpreting your boss's intent; Maintenance requires a different set of skills from other parts of the development cycle; He might be putting you on a job because he thinks, out of all of the people he has available, you are the best for this role; not because he thinks you're not skillful enough for something else.

Maintenance requires a focus on reading code, more than any other role you might have. If you are good at reading, you will be good at maintenance. There are lots of developers, even ones of many more years experience, that just don't have the knack for reading other people's code (or worse, their own), even if they are brilliant at other things.

When you put yourself out of the job of maintenance, you aren't 'convincing management that you would be good enough to do something more important', you are literally taking the work of maintenance away from the living. When you stop doing that job, it's because there's nothing left to do. All problems are solved, either because they have been migrated out of the legacy application, because manual tasks are now automated, or you have convinced the customer that they don't want or need it and never will. If your boss interprets that as 'he's good at this, better keep him here', doing nothing at all, then he is a fool.