The practice of a long or complicated form having a "come back later" option is not unusual: the Inland Revenue for example.
You say that you don't want to burden the applicant with a password or username, but I think you already have sufficient data to be a password/username by proxy: you capture email address, name, DOB, SSN, 6-digit password/reference. It might help to separate out identification, authentication and authorisation. While you capture the email address, name, DOB and full SSN how do you know that they are correct? If you are checking these against a third party database then you can use that data to confirm accuracy as presumably you really do need the full day of birth as well as the full SSN. That data is all about identification and only your stakeholders will know how certain they want to be about identity.
The person leaves and you want them to come back and not burden them with remembering a password, but you are burdening them with having to remember which date of birth they used, which variant of their name, having a SSN or not and finally the six-digit not-a-password. And they have to have entered a valid email address which they have access to.
If the requirement is that the six-digit-not-a-password is something that can be written down then you will have to go with six digits. If the requirement is not specifically that the code can be written down then you could go with a link. You are emailing this anyway. Have a GUID token in the form URL so that all the user has to do is copy-paste the URL. That URL GUID is valid for X days and once the form is complete it becomes invalid. You will end up with a URL that is similar to a Google Doc URL. Your stakeholders will understand this concept and they will potentially think "if it's secure enough for Google then it's secure enough for us"; depends on the level of expertise of your stakeholders. As you know, many sites use this method for a password reset. Your users and stakeholder may not know that this is how some REST APIs work: they have an API key sent in the header, and even SSH certificate-based authentication is really "only" a big old long password.
The advantage of this scheme is that it's easy for your customers. The GUID won't be stored in logs or seen by proxies because you are using TLS. There's lots of entropy in a GUID so almost no chance of collisions. They are impossible to enumerate. You have said that you are going to email the codes so you can just email the link.
There are some disadvantages. A 38 digit passphrase isn't the most convenient if you really want users to type it into a box.
One of the requirements (I missed prior to this edit) is that the code has to be able to be spoken to the service desk. I would go with the URL containing a GUID plus use the last six digits of the GUID as the token and then ask the person to provide one of the identification tokens and the six-digits over the phone or by text message. It's a bit of a cludge but it improves the entropy and provides a way for the code to be spoken. Using the last six digits of the URL keeps everything consistent. You cold use the surname they registered with or the email address. Surnames could be only two characters so that's only another 8 bits of entropy but better than nothing.
There are some disadvantages that apply to this and also apply to the general case of what you are describing: reliance on the security of the Mail User Agent, the Mail Transfer Agent, the end point, overlooking, shared mailboxes. A bad actor who knows the victim may already know their DOB and SSN (I don't have a SSN so I don't know if this is the case, but in the UK the NIN is pretty public). Brute force is unlikely but as good practice you will want to throttle attempts.
You ask about risk on a scale of 1 to 10. Risk is the product of impact to your business and likelihood. I can't answer for the former: you will need to undertake a business impact assessment to determine what the impact of a compromise to CIA is. In terms of impact to the rights and freedoms of the data subject if you were to do a PIA as required by GDPR then you might argue that a single record is a marginal risk to a data subject: there is not much an attacker could do and DOB + name is already pretty much public. Not so sure about SSN. The UK NIN + DOB + name could potentially be an identity hijack risk. A databreach would, I think, be notifiable to the ICO so your impact is going to be 3 to 6 on your scale. A loss of your entire database might be 5 to 8, but this question is about a single record assuming the infeasability of enumeration. The likelihood is requires that you undertake threat modelling: I can't say really how much of a target your database is. If it is very attractive, if for example being able to get hold of a member record directly led to a large cash reward then it's possible that someone could rent a botnet to try a collision or brute force attack. It would be unlikely to succeed of course, but they might try if the prize were worth it. It's more likely though that your database of credentials is exposed through poor internal practice. Your end users are unlikely to be highly security aware, so they may well store the credentials anyway.
Your threat model will tell you if you want to care about user behaviour, the user email or if you only want to focus on the part that you can control. If the site needs to be very resistant to an attack then you might want to consider posting the credentials in the snail mail to a pre-registered address as the UK Government Gateway does.
Assuming that your risk / threat assessment is limited to your technology and the security of the controls that you have in place then a GUID in the URL might be the easiest solution for your clients and your stakeholders should find it acceptable too.
If your threat assessment shows that you just don't want anyone to stumble across that URL during its active time window then you should consider allowing a login via a social media account, eg oAuth etc. That will give you their identity, it's easy for the user, it's "modern". But the downside is that you have to code oAuth which isn't exactly hard, you are giving up a bit of control to Google and of course it relies on your users having such an account.