Preliminary notes about titles:
Sometimes, what you really do doesn't match at all your official title. As an example, years ago, I was hired as an “analyst-programmer in R&D department”; however, nobody hire did analysis, nor programming, nor research, nor development. What I (and others) actually did was coding. A monkey could do half of the stuff I did. Any undergrad intern could do the other half.
Often, the title doesn't matter. In some companies, you may end up doing a lot of different and diverse tasks, and there is simply no title which describes all that. In one company, I did the tasks of an architect, a team lead, a manager, an UX guy, a coder and a productivity specialist, and I was ensuring two teams were communicating correctly with each other. There is no single title for that.
Finally, titles may have different meanings in different companies, or people who give titles in the first place have no slightest idea about the real meaning of the title, if there is any. In some cases, there are just fashionable titles and buzzwords. You don't need a system administrator—that's old fashioned. You need a DevOps specialist. You don't talk about business intelligence or data mining when you try to hire someone: you talk about Big Data!
So forget about titles, and focus on what exactly you were asked to do. Luckily, your question does exactly that.
Is this common? For a very large system, doesn't the code base change all the time?
I haven't seen it, and I don't believe it could be sustainable.
Can this be done?
Yes, but at a cost of normal people leaving the team.
What your manager may have in mind is that you do the design and present it in a form of UML diagrams. It's old fashioned, but who cares? The practice was quite popular in some companies, and still works decently well in others. It may be a suitable approach if you're very skillful, but all other members of your team are beginner programmers: they simply don't have enough experience to do the proper design themselves, and you're in a very good position to help them.
If I were you, I would start by talking with your manager, in order to determine whether it's really this that he has in mind. If yes, play the game, and try this approach for a week or two. What could possibly happen?
Either you'll discover that the approach works well for your team, in which case, thank your manager for his insight, or the approach won't work.
In this case, talk with your team first, in order to identify all together why didn't it work, and what should be done to improve the process (in other words, do a retrospective). Then, either implement the changes to the process if you're in a position to do it, or go visit your manager and discuss it with him.
Then repeat. Every two weeks (or what seems appropriate in your context).