Is there any standard way for knowing when to stop writing user stories, and if so, what is the basis for this, and how does it apply to future sprints?
I don't personally know of a standard method per se. It really comes down to a combination of your methodology, and your customer's expectations.
I have found that it is better to start coding as soon as you have "enough" stories from your customer to make a start. As others have said, this could be for a single iteration, however it could be for more. Your measure of enough should be guided by how often you intend to release working code to your customer, and rather than have your customer give you and endless list of stories (many of which will probably never get done, or might change, or might not make your major release deadline), it's better to ask your customer for the first 3-5 most important and highest priority features. When those are done and released to your customer, you collect the next most important 3-5 features and so on. Ask for more or less depending on how long your iterations are likely to be.
Your customer or contract or deadline perhaps may guide you as to when to actually stop asking for stories, yet in the meantime, you have been asking for stories and stopping as often as you have had iterations. When by agreement you and the customer feel the product is complete enough, you can then decide what to do with any left over stories that the customer may have not given you yet.
The main advantage of this approach is that you end up delivering the greatest value to the customer up front, and as the project grows and time passes, the amount of value you are delivering to the customer decreases to the point whee the customer can make a decision about the "last 20% of features" that they might have wished for which might never actually be used. It also cuts down on time wasted on trivial and low priority items, putting the responsibility (and stress) of prioritizing and scheduling iterations back on the customer, and all based solely on the customer's needs. That doesn't mean however you shouldn't provide guidance to the customer in order to avoid difficult scheduling bottlenecks that may become apparent as you talk requirements with the customer.
Have a read of the Poppendeicks' Lean Software Development if you'd like a more detailed description of this approach in a wider context.