Do I create new user stories to the same effect and copy and paste the acceptance criteria etc into the new user stories?
No. Don't do this.
This is new work, and therefore must be placed on the Product Backlog, prioritized, accepted into a sprint during Spring Planning, re-estimated, and appropriate implementation tasks added to the Sprint Backlog.
Stories are Not Specifications
If you're using user stories as acceptance test specifications, you're Doing Scrum Wrong™. A story describes a need or a feature, and leaves it up to the self-organizing team as it's currently constituted to find the best way to implement it. Putting detailed specifications into a user story defeats this purpose, and using legacy estimates and task breakdowns doesn't leverage the current team's knowledge, experience, or lessons learned to optimize the story
The Stories are Not Identical
You have posted no examples, but I can't imagine that a properly-written user story can be duplicated exactly and remain meaningful. For example:
As a user,
I want feature foo
so that I can effectively quux.
is not the same as:
As a QA tester,
I want the regression tests for the foo feature to be automated
so we can leverage a continuous integration system to prevent regressions.
Even if the features to be tested are the same, the viewpoint and the underlying goals are not identical, and the stories will therefore likely have different tasks needed to implement the stories.
Backlog Items Must Be Re-Prioritized and Re-Estimated
Is this new automation feature more important to the Product Owner than some other greenfield feature? The only way to be sure is to add the automation stories to the Product Backlog, and allow the Product Owner to prioritize them.
As the team accepts these stories into sprints based on backlog priority and current team capacity, the stories will also need to be re-estimated based on:
Current team capacity.
Automation stories may not change your overall velocity, but they will likely reduce your capacity available for new features.
Current team knowledge.
What was a large story 20 sprints ago may now be a small story based on new team knowledge or processes. Then again, maybe the team now knows more about how complicated certain types of testing are, and the old 3-point testing story is now really a 20-point integration story with many more dependencies. This detail should be driven out during Sprint Planning.
Current tasks needed to implement the story.
Developing product features rarely consists of the exact same tasks needed to automate infrastructure or testing. There are edge cases where automation was addressed early in the project as part of the "definition of done," but new work always requires new estimates.