You Already Have Good Ideas
The ideas you outline in your question sound excellent. It is a big surprise that you are not finding success. It is 2012 and the object-oriented revolution has long since passed from state-of-the-art to state-of-the-practice. It seems like unless you have very low turn over and very little hiring, you would have a hard time not getting several dozen or even a hundred good solid object oriented programmers.
Agile or Object Oriented?
You mention some Agile technologies like TDD and some newer concepts, so don't be too harsh on people for not embracing something that is still actively fought by some management teams. Some claim to embrace Agile, but when they talk about it, it means what they say it means. The organization is not characterized by teams that make decisions and adapt, but instead by strong hierarchical contract-style control.
But back to object oriented. You don't mention object oriented analysis or design, and I am not quite sure which programming language is giving way to which object oriented programming language. I know UML is having popularity problems among many object-oriented programmers. Having been thoroughly trained in OOAD, I believe that it may be like learning the culture and history of a country whose natural language you want to learn. For example, if I wanted to learn Greek, I could learn the alphabet, vocabulary, and grammar, but if I ignored the rich history and culture, I would miss a lot. In any case, if you learn all about an object oriented programming language, but nothing about OOAD, I think an important opportunity has been lost.
Problems to Overcome?
Bridge too far? If you ask people to learn one small thing a week, in a year, among the people who participate, there will be a lot of change. If you ask them to change everything they know, it will be welcomed by a few, hard for many, and impossible for others. Some changes like source control are localized. You transitions from not doing it before, you had training that was not stressing the limits of memory, someone walked you through it the first time, and then the day-to-day was pretty easy.
Other changes are pervasive. For example, dumping C and switching to Java requires significant training, setup, and big changes in the day-to-day to adopt a new IDE, new compiler, new language, new API, new deployment model, etc. This is the kind of thing that happens most often in conjunction with a pilot program or corporate restructuring.
Leading a Revolution? If the people currently doing the work have a history of being rewarded, and the company does not seem in danger of failing, what is their motivation for change? If you seem like an outsider who wants to point the direction and leave them accountable for results they can't predict, it may seem like all risk, no reward.
Position Power or Idea Leadership? Many organizations operate based on position power. If you lack visible support from managers, sections heads, directors, and Vice Presidents, you are merely an idea leader. Some people are in the dangerous position of having one idea, and not being able to entertain a second one. If you can show them instead of telling them, that will go a long way to quiet skeptics and to interest talented allies.
Base of Support Too Small? Do a triage among those 250 people and sort them into three categories: ready to embrace, willing to learn, and unwilling to learn. You have good reasons to be frustrated with some of the people who have no interest in making a change. You might as well be pushing on a rope. This is wasted effort. If you have a feel for who supports change, you can find out what interests them.
Unlike a medical triage where the ethical and practical choice is to help the middle group that can make it with help, you can invest your energy and time based on your judgment and preference. For your success, why not cultivate the group that is ready to embrace new ideas? They may be few a first, but like a snowball, your visibility and credibility as an advocate will grow. Soon people will be asking you when the next training will be.
In it for the Long Term? Until you cultivate a champion to carry things after you, you should expect to invest time building relationships. You may need to stay with the teams you coach for more than one month. Until the team owns improved practices for themselves, you are just a technology or methodology cop. Mentoring is a process that can take years. There are a lot of things your developers don't want to do that you think are important (you specifically mentioned unit testing I think). It may take a while to build a shared vision of the value this brings. I know this by experience because I once advocated for a code coverage tool at a Fortune 500 company that had a great reputation for quality, but managers and peers alike were wary about committing to it.
Expert or Grassroots? Much faster than mentoring would be to foster grassroots support that comes from each team member. Starting with a team of ten software specialists, if I had my choice to have one person work on process all the time or ten people work on process ten percent of the time, I would pick the second. Grassroots process permits the advocates to feel the impact of the approach, and for the approach to be tailored to best solve the problems of the team who owns the work.
Do you see the Freedom Line? Part of introducing "Best Practices" is to get people to give up some freedom to do things in a common way. Giving up programmer's discretion will be more palatable if you look for opportunities to leave many choices to developers. What they pick is delineated from what is mandated by a partition that we can call the freedom line. It may be necessary to similar, well justified divisions about organizational, regional/site specific, team, and personal practices.