What you're describing sounds something like trunk based development. Your team is committing everything to the stream as it is done. When you want to make a release, you cherry pick your changes (i.e. you want story 1 but not story 2 in the release). In trunk based development, you create a branch (i.e. you create a new stream) where you will merge in the cherry picks. Typically, a release engineer will perform this task and is responsible for merging in the changes.

My recommendation is to create a second stream that will represent the release. It will begin at the starting baseline. With your repository workspace, accept all the changes from the main stream. Then switch flow targets to your release stream. Pending Changes can switch views to show outgoing changes grouped by work items. You'll see your change sets grouped by your tasks and you can deliver the ones from story 1.

There might be some change sets that can't be delivered due to the delivery creating a gap. This is due to the nature of RTC's design as a change set based source control. Some of your cherry picked changes may build on top of changes from story 2. You'll have to merge these manually by creating patches from the cherry picked changes. Until the upcoming gaps support is completed, there is no easier way to merge in your cherry picks.