Your use case is contextually not any different than re-displaying a simple single page form that user failed to fill in correctly, and for sake of convenience your server code re-filled the fields that user did fill in correctly. We see many such examples across the web. The only difference being, that you use two pages for a complete set of required (and optional) user data you're collecting. You could as well be using twenty of such steps, it doesn't really matter from security perspective (it might to the users tho, but that's a different matter), as long as:
- You've taken care of TLS
- You treat all user inputs, regardless of the page they come from, as a whole
- You don't unnecessarily expose clear text passwords in end user cache
You mentioned in the comments that this will be on HTTPS, so the first one is taken care of. Both of the other two are completely manageable, too:
Your server side code that verifies user input will have to be written in such a way to accommodate multiple user form pages, but also check against input constraints incrementally, meaning each new page will check all the data input on previous ones as well, up until the page the user is currently on. You also only accept all these separate forms as a whole, meaning a failure on one reverts to displaying that particular end user input stage, drops all subsequent form data, and displays relevant error for that page (or stage, step, however you want to name it). The important part is, that you accept all of the user's input only once all data is verified against your requirements in all of the form entry stages. Only then you can safely write anything to your database - i.e. all requirements were met.
Why is sending back end user passwords in clear text not a problem? Because you've already sent it at least once in the other direction - to the server. If that's not supposed to be a problem, sending it back using same TLS shouldn't just as well. Shouldn't, because you'll still have to consider this data being cached at user end by the browser, as @ThomasPornin pointed out. This is however controllable with browser cache header tags, be it as HTML tags, or in the HTTP server response headers. I won't go into detail how to achieve that, as it's a well covered subject, and has many threads on StackOverflow as well. The main takeaway is, that if your front-end was already prised open by some XSS injection, nothing is stopping this injection from collecting end user data on form submit from that same input field, so sending it back doesn't really expose it any more for these types of attacks, but client cache should still be considered to prevent exposing clear text passwords to other attack types.
Others have also suggested using AJAX for parts of your form data. While true that it can help with user input, guiding users as they go with feedback, you should never accept only partial data as something to rely on later, when completing either stage of form submission, or when completing the process as a whole. Checking display name availability, or similar is fine tho, but if it's in the mean time taken by another user, you most certainly don't want to rely on that previous AJAX request to decide, if the current user still gets to use it.