I don't entirely agree with maple_shaft's answer, but there wasn't enough room in the comment to say my entire bit! ;-)
I agree that every developer can and should be an architect, but that does not mean that every developer should be responsible for the architecture of an entire product or system. Further, I don't think you can paint every architectural team with the same broad brush, and when done right architectural teams can deliver great value to the overall product development process. The misconception is that the architects should dictate every aspect of the system design. They should instead focus on the higher level design, and leave the implementation details to their development teams. That isn't to say however that the developers shouldn't be involved in the planning and design process from the outset.
The larger and more modular and ultimately more complex a product is, the more likely you will find various parts of the product handled by different development teams. Such teams need not understand the system as a whole provided they have a full understanding of the parts of the system that they are responsible for. Often these additional teams are brought on as subcontractors for the specific purpose of developing a module in a particular area of technology that the architects or other teams may not have expertise in. My own particular talents lie in developing API's, and I have yet to see a well factored API that was developed entirely organically without either being a complete mess in terms of usability, or that did not require someone to stand out as the person who ensured there was a level of uniformity between different aspects of the API. I can go on to list many examples and reasons, but I don't think that these sort of situations are the ivory tower BS that many might think they are. Unfortunately, there are many places, particularly in areas of defense, medical, and the financial sectors where corporate paranoia does result in poorly specified and even more poorly managed product development of the sort that I'm sure maple_shaft was most concerned about. These are the things that I believe give architects a bit of a poorly deserved bad name (generally speaking).
So where is the middle ground that the OP was looking for? The answer is all to do with opening channels of communication. The architects need to hand over specifications that describe their designs in enough detail so as to ensure the development teams will understand where the boundaries are. Stories and Feature Scenarios in the broadest sense, where everything is considered a black-box. The architects then need to ensure that the teams have access to the architect's time to confirm any assumptions, and to have any questions answered about specifications that seem too broad, or unclear. After that, it's really about ensuring that individual teams are made aware of what the other teams are working on, and that they know who to liaise with on the other teams to ensure each part of the system will play nicely with the other parts. These teams meet each other directly. Once the system has been designed at the broadest level, the architects should really just be the people the teams turn to when they need a sanity check, and to ensure that the product "vision" is maintained. They should also take on board any integration process required, and provide much needed "air-cover" for the development teams from the managers, customers, and any other stake holders, while still ensuring these various people can all get together to work out between them how things should work.
IMHO architects should first and foremost be facilitators & communicators, and designers second. As to what level of specification? I think that the best architects are the ones who ask their teams about the level of detail that a team wants, and between them find a balance that works. Different teams may have different requirements in terms of the amount of documentation or direction required. Senior teams may find a roughly drawn diagram and a quick chat may be enough to get going with, while teams filled with relatively junior developers may require a little more to get them going. Above all, the architect needs to encourage developers to exercise their own design talents in order to get the best end result from each team.