Requirement/story building tasks

I don't think this approach makes sense.

I'd start with terminology. If you're going to call something a user story, make sure that it is a user story. User stories are descriptions of features or functionality of a system written from the perspective of the system's user. Fundamentally, a story is a lightweight, natural language description of features and functionality. There are alternative structures, such as job stories that focus on the job being done rather than the person or user class doing it, problem stories that focus on the problem being solved and the solution desired, or improvement stories that describe current state and future state. Maarten Dalmijn has written about these and other alternatives to user stories.

The Scrum framework doesn't talk about user stories, or any kind of story. Instead, the Scrum framework talks about the Product Backlog and Product Backlog Items. The use of stories, whether they are user stories or some other type, is a common approach to capturing Product Backlog Items. However, Scrum doesn't mandate one approach or format or structure over another and leaves this up to the teams to decide. However, the framework is clear that the Product Backlog contains an "ordered list of what is needed to improve the product".

Not all work done by a Scrum Team is suitable for the Product Backlog. There are plenty of things that the team needs to do and keep in mind when planning. Product Backlog Refinement is one such activity. Refinement is about creating, decomposing, adding details to, tracing, and otherwise working with Product Backlog Items. The work needed to carry out Product Backlog Refinement, since it doesn't directly improve the product, doesn't go onto the Product Backlog and isn't captured in Product Backlog Items.

Scrum is silent on how the team manages their work. It's just clear that it isn't in the Product Backlog. That doesn't mean that you can't track the work in the same tools, just that it's not a Product Backlog Item.

I would turn to the team to solve this problem. There is a Product Backlog Item somewhere already. It's not ready for selecting in a Sprint Planning yet, so refinement is needed. How does the team want to track the fact that there needs to be refinement of this work item into discrete product changes? The answer to this question depends on the context of the team and the tools at their disposal, and there's no one-size-fits-all approach.

This is a data migration project so there is arguably more work in developing the stories/requirements than actually implementing them.

You could be right about that, in so far as data migration tends to be complicated rather than complex. There's lots to do, but it is mostly well understood, and there is typically little need for innovation. The biggest risk tends to be around handling data that is poorly normalized or of obscure and incompatible type. So why use Scrum and conversational placeholders like user stories?

I might be inclined to make "map customer fields from source system 1 to the target system schema and implement the mapping" the Product Backlog Item.

I have done data migration projects using the Scrum framework.  Honestly, it added unnecessary overhead to the process because as @Ian said it was complicated work but not complex.  

His second sentence sums up why.  You know what work needs to be done.  Sure, there are multiple ways to map fields from one database structure to another.  And there could be more than one way to convert a text field to a date field. But it isn't complex and needing the ability to attempt something then adapt. We found that we were copy and pasting one project to form a new one because it was so similar. Scrum is not very useful for that type of work. The problems you are facing are probably self caused.