tl/dr Your setup assumes that an attacker can't read requests from your server. This is only true for in-browser requests. However, a
therefore an attacker has no reason to be making requests in browser.
As a result a core assumption you are making (that the attacker can't
read responses from your endpoint) is invalid, and this security step
is largely useless. Now that it is causing trouble for your end
users, you should ditch it all and stick with more common brute-force
monitoring. Off-the-cuff security measures tend to create more
problems than they solve - stick to the basics. I don't think anyone
attempts the kinds of attacks you are worried about anyway. A full
site DDoS is probably easier, so no one would bother trying what you
are worried about.
There is definitely some confusion of terminology going around that I think is worth addressing. Most importantly, you keep using the term XSS but this is not an XSS attack. I agree, your concern isn't exactly a CSRF attack, but it definitely isn't an XSS attack either. The reason is because you seem to be under the assumption that such malicious attacks would come from a browser: in a case like this they absolutely wouldn't (which is why this isn't a XSS attack).
This is more than just me being pedantic. You mention in your original question that about
Access-Control-Allow-Origin and other CORS settings, and state that a malicious user could hit your endpoint but not read the response. Again, this is only true from requests made from a different domain in a browser, but in a case like this there is absolutely no reason why a malicious user would be using a browser. The only reason you would work from inside a browser is if you are trying to take advantage of a user's cookies for authentication (which is the case for CSRF attacks). however, this is a login endpoint, which means there are no cookies, and presumably therefore no reason why the attacker needs to be doing anything from inside a browser. That is to say:
A malicious attacker could use any HTTP client to make these login request, they wouldn't be affected by CORS rules, and would absolutely be able to see the response from your server
Back to your question
So you have this extra security step in place to (effectively) try to prevent malicious attackers from attempting various DoS attacks on your login page. You specifically mention these concerns:
At the very least the attacker can rate limit the users IP address. If
they target a specific email, they can make it look like a DDOS using
many (real user) ip addresses and lock out the email. If they have
access to the network traffic they can even analyse the response
package size to determine if a login attempt was successful
(Distributed Brute Force).
As stated, your current step is not actually protecting against most of this. In particular, there is absolutely nothing stopping a malicious hacker from setting up scripts on dozens of different of ip addresses (even just rent-a-vps from a cheap hosting provider), hitting up your GET endpoint to get an access code, and then (with the same IP of course) hitting up your login endpoint with that access code and a chose user's email address. This will look like a DDoS of a user's email address (because it is) and from the sounds of it will result in that email address being locked. They don't need to bother analyzing network traffic to see if the response is successful because they will be able to read the response themselves. Again, it sounds like you were assuming no responses from your server could be read, but this is only true for browsers, and does not impact HTTP requests from any other HTTP client.
All that to say: regardless of whether or not this attack is a general concern on the web, the method you have chosen to defend against it and which is causing trouble for your customers is not actually providing any real protection for your system at all. As a result, the overall answer is easy:
Ditch this security step and make life easier for your users
You also asked:
Should we worry about this attack?
The answer is a simple no. Technically things are rarely yes/no in security, and the answer is always "It depends on the level of risk you are willing to accept and your expected threat model". However, unless you have reason to specifically expect this kind of attack in the near future, I would say that it is not a concern at all. I've never heard of such an attack happening in practice.