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.
For example, if you advertise a front-end developer position for a company producing web-based software, you should get people who are strong in technologies like CSS, Javascript, HTML and who might have some knowledge of graphical design and/or human/computer interaction, but those latter aren't their main focus. They will expect to be given reasonably solid designs for how something should look and interact with the user, and be tasked with writing the code to make those things happen.
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 it will/or user frustration when the software violates the user's mental model of how the software should work almost as well").