The first thing about being honest with your developers is telling them exactly why they weren’t hired if this was indeed the case. Most companies I’ve been to, either rejected me after an otherwise seemingly successful interview, or even sent me an uninformative rejection letter before any interview. This will cause the exceptional developer to wonder what has he done wrong, or what’s wrong with him.
As an employer, you should have the minimal decency to inform the star developers what they did wrong and how to further improve. Otherwise, you’re not being fair with them, and they also may tell all their friends how pointless it was to try to apply for you. (Or tell their friends how good a different company that’s also looking for great hackers treated them.)
Honesty is also telling your developers when they did something right, like finding bugs, fixing bugs, having good ideas, implementing something on schedule, handling a situation properly, etc. and when they did not do something properly. Even the greatest developers make mistakes, but you should be honest enough to evaluate their total performance so far and not just their isolated mistake. A great developer who’s worked for you for a few months, made a mistake recently learned from it, and is determined not to repeat it, is a better asset than a new developer who still has a lot to learn at the company.
Obviously, honesty goes in both ways. Great developers should be honest enough to tell their future employers, present employers, and co-workers what they think about them, or if they believe themselves or the latter are doing something wrong or exceptionally well. Honesty is both liberating, and makes sure one avoids problems and problematic patterns.