I've found many parallels with the four stages of learning in software development, from how a developer's approach to design changes to how agile teams eventually become self-organising (eg, Scrum's "readiness levels"). By understanding where someone is on their path to becoming truly good at something you can be more effective in mentoring them to the next level - rather than assuming you can fast-track them right to the top.
There are other classifications of people's abilities and how they learn. The Dreyfus Model, for example, lists five levels (Novice, Advanced Beginner, Competent, Proficient, Expert). Understanding one of these models is a useful skill, especially if you can use it to adapt your teaching or mentoring style.
In the first stage of learning you don't know you're no good - ignorance is bliss! Sometimes this comes from simply having preconceptions about how easy a task is and sometimes it comes from not knowing there's a better way. Dysfunctional teams and developers are often unaware of what they're doing wrong, even if it becomes obvious when scrutinised.
It may be hard to mentor unconscious incompetents as they don't think they need to learn anything. A more formal, indoctrination-style, approach might be appropriate.
The second stage of learning is the tricky one as it starts to dawn that you're not actually all that good! At this stage, teams and developers need a lot of support to prevent them wallowing in despair and to help them select and adopt new techniques.
In the third stage of learning you're consciously applying the techniques you need in order to be "good". Here teams and developers know what they should be doing but need their momentum to be maintained, often by external encouragement and review.
At the fourth stage of learning you're naturally doing things right. The investment in mentoring and training is paying off here, but this can lead to risks, particularly a lack of thought and communication.
Architects are typically highly-skilled, often naturally adept in their domain - they're often at the unconscious competence stage of software design. This is not without its problems, though, as there is an element of truth in the saying, "those who can't, teach". Perhaps it's more diplomatic to say, "those who can, can't teach"? People who are naturally talented often struggle to explain how they do what they do. My wife, a teacher, often jokes that I couldn't teach her maths classes despite being more adept at the subject. She's right - I can't even tell her how I add two numbers in my head (I can, by the way).
In more subjective domains, such as the arts, an unconscious competent may never be able to teach someone who is not also naturally talented. Software design is not a totally rigorous discipline and perhaps the trend for "good taste in design" edges into the artistic skills? Should we expect to be able to teach these things? Should we expect someone to develop a style that we'd consider good taste?
If I think about the people I've learnt the most from, their skills have never seemed unattainable yet, on reflection, they were probably more adept than the self-proclaimed "gurus" who often rely on intellectual violence.
Somehow you need to analyse your own actions, essentially acting like a conscious competent. Rather than trying to force something into the mentee's subconscious, try to bring discussions to their level so they can understand it in their own way. By mentoring you are pairing with someone - you can supply the competence, they can supply the consciousness.