Since you're doing Scrum, let's look at the guide:
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
Why does scrum take such a strong stance against the sort of thing you're trying to do?
Your team is not regularly and reliably producing shippable software. At the end of a "dev sprint" it isn't tested properly, so it's still work-in-progress. More testing and potentially more dev effort is needed. It's not shippable.
If you're lucky and the regression tests all pass first time without dev effort, that’s shippable. Otherwise, you have the choice whether to derail the new "dev sprint" or just record (potentially serious) bugs (/failure of stories to be delivered to acceptance criteria) for later. Neither of these is a good outcome and neither result in shippable software that sprint.
You've damaged your ability to respond to change. Let's assume that this is one of the weeks we get lucky with the regression testing and everything passes. We hand the software to the customer and do our demos. We get lots of useful feedback. Unfortunately we already decided what the priorities of the next sprint should be last week.
You've divided up the team A team committed to delivering a goal is a powerful thing. This sense of shared responsibility cannot really exist in this situation. QA and Dev are working towards different goals. When a Dev helps a QA complete their sprint goals, the dev imperils their own. People become less T-shaped as responsibilities are heavily siloed and there isn't a sense of everyone pitching in towards the same goal. Team dynamics are incredibly important and this will matter more than you probably think it does.
So what should you do?
Regression tests that take 3 days aren't something you should work around, they're something you should fix. Sorry, Scrum isn't an infinitely malleable process that can cover for teams that don't want to adapt, improvement and fix their underlying technical problems. Which is why, incidentally, much like Extreme Programming (XP), it isn't for everyone.
Unless you're selling tickets for the most boring spectator sport of all time, you're job isn't to "keep developers developing and tester testing", it's to deliver value. If you have to take on less work, finish a bit earlier to allow for 3 days of testing, do that. In exchange you get the opportunity to continuously release actual done working software, it's worth it.
You can always use the dev time towards the end of the sprint to improve the speed and automation of your tests. QA time towards the start of the sprints should also be used for this, as well as things like exploratory testing. Good CI and good automation will be big wins for your teams productivity.