What I've done in the past is give an estimate based on what a “standard” dev can be expected to do (everyone understands a junior is expected to be slower as they are new, that is why they are currently a junior and when they get up to speed they'll be promoted) with a comment on the ticket that the expected time will reduce by × if a named resource, or one of a group, is available to work on it. That way, medium term planning can be done on the basis of a “reasonable case” scenario and if the right people are available things will go better (and if there are multiple items in that state, short term planning will include deciding which ones being sped up, by using that person's time, confers most extra value).
I like to think of it like Algorithm Analysis; Best-Case (estimate by the expert mentioned above), Worst-Case (estimate by Noob who just joined the project) and Avg-Case (estimate by person who is already part of the project but is not responsible for that module). Add a fudge factor based on your reading of the circumstances and then haggle with Management. You now have a band with a upper bound and lower bound which can be realistic.
PS: You may find Douglas Hubbard's How to Measure Anything: Finding the Value of Intangibles in Business useful in this regard.
But, but ... isn't every estimate supposed to be provisional? Aren't you supposed to be re-estimating regularly?
Heh, no. It is an estimate when you are making it, but ten minutes later it magically becomes a commitment.
"Tasks like this usually take two days, sometimes one or three, very rarely more... so, two days on average."
"Okay, I am writing down: two days."
...two weeks later...
"How it is possible that the task took three days when it was estimated at two? You made the estimate! And you all were there at the planning, and no one said anything! As senior developers, you should make better estimates, this is unprofessional."
