In my opinion, you're getting closer, but still a bit off.  Maybe something like this...

FUNCTIONAL REQUIREMENTS (I think it would be more aptly stated as "functional solutions" rather than "functional requirements"):

• A user name and password will be required to enter the system.
  • Each user's user name must be unique.  (Any length contstraints?)
  • The password must be a minimum of 6 characters in length [I'd also add something like, "...and a maximum of ______ characters will be allowed"].  (Or, "The password must be between 6 and _ characters in length.")
  • User names and passwords will be alphanumeric.

SYSTEM REQUIREMENTS (again, "solutions" is more accurate, in my opinion):

• JavaScript logic (specify general logic) will validate that input value is alphanumeric.
• HTML "maxlength" attribute will be user for both input fields to control length.
• AJAX will be used to ensure that user name input value does not exist in system.
  • IF name exists, THEN return

Well, maybe I jumped a bit ahead of myself.  I see the functional requirements as the bridge to the system solution --sort of a blueprint, maybe?  Stakeholders and developers are both involved.  I guess what I meant was that sometimes the functional requirements are defined purely by the stakeholders; at other times they entail solutions by the developer.  For instance, to me the user name and password screen is more of a proposed security solution by a developer, not a requirement by a stakeholder.  Where I work, stakeholders expect everything to be secure by default and depend on the subject matter experts (developers) to accomplish that; but they also want to know, in layman's terms, the functionality of how it's going to be accomplished.  Hence the user name and password's inclusion in the functional requirements.  The system solution, at least the way we do it, involves only the developers.  Where I work, we just have one "Design Solution" document that includes functional requirements/solutions.