@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.