I think that you are thinking about this a little too hard. Functional and non-functional requirement are not really as separable as you are suggesting, Take the login case for example.
The user SHALL be able to log in through a web interface. Technically, this is a functional requirement.
The system MUST respond to log in requests within 1 second. Technically, this is a non-functional requirement.
Either way they are both just as important regardless of specific classification.
Requirements can come from any number of places. You might want to have better performance than a competitor. A customer might have specific needs. There might be a request from marketing or sales. There isn't one place were they come from. Though, you could probably abstract away all the different sources and refer to them as customers. Ultimately that is what they are.
You can identify the difference using the following metric. Functional requirements describe what a system will do. A non-functional requirement specifies how it does it.
Explicitly separating requirements will make it easier to design the right system.
With nonfunctional requirements (I prefer the concept/term quality attributes - should provide new insights beyond functional vs. not functional), you are more concerned with the properties of the software rather than the functionality. That is how the system performs some function, not simply what the system does. Quality requirements have a significant influence on the architecture of the system in ways that the functional requirements do not and for this reason they should be treated differently.
Keeping the quality attributes separate from functional requirements allows you to analyze, specify, and prioritize different kinds of requirements in different ways. For example, quality attributes are normally specified using a quality attribute scenario while functional requirements might take the form of stories, use cases, shall statements, or any other number of formats. Most of the systems I've worked on had less than a dozen quality attributes and many, many more functional requirements.
I would actually introduce another kind of requirements - technical constraints. Again, explicitly separating the requirements into these three buckets gives you cues for how to make the right trade-offs while building the system. Functional requirements are often quite negotiable, quality attributes will heavily influence your architecture and the structures you choose, technical constraints are non-negotiable.
If this were my team, I would tell them the requirements should be clearly annotated by type to make sure we don't miss something important in the architecture. Think about the architectural drivers, not just the functionality.
Anthony Lattanze in Architecting Software Intensive Systems: A Practitioners Guide gives a practical overview of architectural drivers and why they should be treated differently, much more comprehensive than my summary here.
Best Answer
Based on my understanding of the English language and trying to be logical about what should be the difference:
Requirements Elicitation = Requirements Gathering. This is asking what are the requirements, what if this, what if that, etc. This is about asking the questions and getting responses. How well are the answers is another matter entirely. This requires the stakeholders to answer their part of what is to be done and why.
Requirements Analysis. This is more the organizing of answers to the first part. Which solution is optimal? What are the trade-offs of various possible implementations. In this part there may be the odd question but it isn't the main point as this is about seeing which solution may be better under various constraints,e.g. which is the fastest or cheapest. This is more about how is something to be done and why does that way make more sense than another.
Another way to think of this is that the Elicitation has to come before the Analysis as otherwise you are analyzing nothing, which may not be that useful or productive.