TL;DR: I don't think pair programming would work for you. Instead you should try to get people concerned about the long-term quality of their code and make them want to find answers. This has to be done informally.
About culture and quality
I feel this issue is not about programming methodology but rather about culture.
In my experience, culture is possible to direct, but rarely by telling people about it. That is, trying to force a certain workflow on people that hadn't evolved naturally or is too far removed from the existing practice is bound to have negative consequences.
In other words, you don't want to look like the suit who comes around buzzing the latest buzzwords, even when ultimately you are. Most programmers I know would mentally tag you as background noise. Don't be a corporate bee.
In my opinion, the primary question you should be asking yourself is "am I happy with the quality and business value of the code my organization puts out?" and if the answer to that is negative, you should ask "how do I turn this around?".
Ultimately, quality and value are human definitions only you or someone else in your organization can (and should) think about.
Pair programming and micromanagement
So, at the risk of sounding a bit forward and harsh, it seems to me that reading about pair programming actually got you thinking about some form of micromanagement, or the other way around. MM is a sure-fire recipe for alienating most people.
In defense of pair programming: pair programming is not about some guy looking over some other guy's shoulder. That is as micro as management gets. PP is about using two minds to think about two levels at the same time - one person deals with high-level, big picture issues while the other takes care of the nuts and bolts needed to produce working code. And in my humble opinion, it rarely works well if the two participants are not in a position to switch places. They ought to be similarly-experienced enough to have a similar professional arsenal of concepts and a shared professional vocabulary (we're not mind-linked - yet, muhahaha).
For your situation, I'd say since you're a small team and you're the only one with real experience (that's what your post sounds like to me), pair-programming or reviewing most of the code most of the time wouldn't work. You only have 24 hours a day. Instead, some solutions you could consider:
Encourage them to participate in SO under the appropriate language tag, or to post some code snippets for review on Code Review SE. Start a little informal contest over who can gain the most SO rep points per week.
SO can do wonders for newbie developers since it provides constant feedback and follows the heartbeat of the community.
Take a look at some of the code they check in and challenge them informally with some questions concerning its long-term evolution. Most beginner programmers are simply not accustomed to thinking about making their code readable and maintainable. Once you get those issues into their heads, they'll seek more information on their own, from you or other sources.