I am not familiar with TFS (is that a software tool?) but I can give you some answers based on Schwarber.
1. Story Containers
There are only two containers of stories that you should ever be thinking about, the product backlog and the sprint backlog. Software tools for tracking scrum may allow you to keep around old sprint backlogs for historical analysis and that is ok, but you must close out an old sprint backlog (i.e. make sure everything in it is finished or moved out) before doing any work on the next sprint backlog.
Sometimes there is a tendency to create the next sprint's backlog in a software tool while still in the current sprint. Do not do this. If that future sprint backlog is there, people will try to put stories into it. This disrupts the proper planning process, raises tensions, and confuses scheduling issues.
If you fail to keep proper boundaries between your sprints then you are, in essence, running multiple, similtanious sprints. You are multi-tasking. At the very least the overhead of task switching will slow you down; research indicates that a full context switch in humans, from puzzle A to puzzle B, takes 15 minutes. My experience suggests this drag can be 50% or more of your productivity.
2. Epics
Keep your epics around. Someone asked for this feature, they will probably come back and want to know the status of the epic. That person, department, or customer will be thinking of the 'story' they submitted, now promoted to epic. They won't be thinking about the smaller stories involved and may not even recognize that story Foo is related to their request. The epic is a convenient handle for communication between development and the customer.
Since the epics don't actually get worked on themselves, just the associated stories, the epics move directly from your product backlog to your finished pile.
3. Where do the stories go?
A story should only be in one container at a time. It should start out in the product backlog, move to a sprint backlog, and then be finished. If someone comes looking for their story in the product backlog and doesn't find it, that must mean it is in process or finished.
4. Final thoughts about managing a deep product backlog
Force-ranked order becomes pretty meaningless when you have hundreds of items in your product backlog. Sure, the how you arrange items 20-70 might be fairly meaningful, but who really cares if #300 is before or after #301?
One possible solution to this is to have multiple sub-component backlogs that feed into a main product backlog. For example, you might have UI, DB, Backend, API, Infrastructure, and Technical Debt as your sub-components. Each component backlog might be delegated to a different person for management. A periodic meeting would have to decide what stories to move onto the main product backlog. In order to maintain a proper balance of stories in your product backlog, it is best to decide a priori a guideline (not rule) for the proportions of stories that get promoted to the main backlog. One API story for every two UI stories? How many stories can you take from Technical Debt in comparison to the number of Backend stories you need to take?
This system adds considerable complexity and requires lots of extra coordination. It should only be undertaken when the the product backlog grows so large that the Product Owner can't think about all of the stories at once.
This depends on your tooling somewhat. From a process standpoint, once the Epic has been broken down into Sprint-Sized stories that can be estimated, the original Epic (which had really been functioning as a placeholder in your backlog) can be discarded. If you are using index cards, tear that Epic up!
Ideally, the resulting User Stories should be independent of one another, so their Epic ancestry would not be important. But if you want to maintain a connection to the original Epic, many tools provide a way to link it. This can also be done in the User Story itself: "[Epic] As a System Admin, I need....".
Best Answer
When you gather requirements, you typically interview people, read and evaluate business or technical papers, or you look what competing software already provides or misses. You will get lots of ideas, on lots of different levels of abstractions. If among these ideas and input you find clean, short and precise problem statements, there is no need to inflate these artificially to an "epic". You use an "epic" if you cannot immediately break down the idea for a requirement to a smaller sub-problem, and you use a "user-story" when your input can be immediately written down in form of a "small user story". And thats it.
This is mostly independent from being in a point in time where no software is written so far (what you call "discovery phase"), or a point in time where you already have a working product and can describe any new requirement in form of a change to the existing software (which should be the 99% case in agile). Indeed, when you have a working product of a certain size, it will become certainly easier to describe several requirements in detail by referring to the existing product and writing a small user story which describes the requirement in form of a change request. Nevertheless, even if the product has already lot of features, expect users to come up with new ideas at any point in time which require an "epic" as the appropriate form of description.
Note also that the typical "life cycle of an epic" is that it will be broken top down to user stories which can be developed individually (and not the other way round), because an epic is typically too big to be developed in one sprint. There might be cases where lots of individual, detailed "user stories" inspire an "epic", because one gets a "bigger picture" from a collection of ideas - but it won't make sense to throw the related user stories away then, because you will need them either for the detailed sprint planning at a later point in time.