I'm worried by this point in your question, which I feel may be at the core of why you are asking this at all:
I'm working to expand our capability by adding front end devs so we can have better relationships with the developers via the front end dev, or translator.
- Serve as translator between dev and UX
That's not what a front-end developer position is about!
Notwithstanding the issue of separating development of various application tiers onto different individuals, which is a point well worthy of consideration raised in other answers to this question:
A front-end developer, in accepted parlace, is a developer who happens to work on the front end (user visible parts) of an application.
If you advertise a front-end developer position and people find out that instead of doing development work they will be asked to "translate" between your other developers and the UX team, then at best, your applicant acceptance rate will plummet, and if it does not, then your retention rate will plummet.
The developer position opposite of front-end is not a developer that doesn't interact with your UX team, but rather a developer that works on the parts of the application that are not directly user visible (web services, database code, that sort of things).
Your other points (build reusable code and libraries for future use, ensure the technical feasibility of UI/UX designs, optimize application for maximum speed and scalability, and assure that all user input is validated before submitting to back-end) are things that any developer should be working towards (or be capable of working towards) anyway. If any of your developers are not, then find out why and work to rectify that situation; adding another layer between the people who want things and the people who build things isn't going to make any real difference there, and if anything, would seem to introduce risks.
It's great if you are able to have a dedicated person to serve as a contact point between UX and development, but that's not really a development position, but rather a human/computer interaction design role ideally filled by someone with some insight into relevant areas in programming and software development. Ideally, this person should also be a subject matter expert in the use of the software you are building, particularly if you are building specialized software that targets a niche market rather than something generic like an e-mail client or image viewer.
In practice, unless you are a big company, it's more likely that the work of ensuring the implementability of what the UX team wants (based on specifications, user stories, UI mockups, etc.) will fall on different members of the existing development team depending on the focus of the issue at hand and the individuals' respective skills. A good development team will be able to shoot something back at the UX team with a rough estimate like "yes, we can do it the way you want, and it will take X days, but if we change A to B instead, we can get it done in a quarter of the time" or possibly "sure, we can do it the way you want, but lots of people are likely to expect the software to work in [describe some other way] instead". It is then the job of the UX team, together with the stakeholders, to judge whether doing A instead of B is worth the estimated additional cost (in time/money spent on development, and/or user frustration when the software violates the user's mental model of how the software should work).