If you are concerned about a text field being abused to perform SQL injection, then input sanitation is not the correct solution to be looking for.
If the text field was completely free form, then every character which could be used for SQL injection would be valid input. If you try to avoid SQL injection by sanitizing inputs, you end up rejecting valid inputs. In other words, you may have avoided SQL injection, but you did so by introducing an additional bug not by fixing one. From the user's point of view, there are at least as many cases of valid input not working as before, maybe even more cases than before.
The proper solution to avoid SQL injection is to use escaping or parameterized expressions (which avoids injection at one layer of the protocol stack by moving the responsibility to a lower layer).
As long as you do escaping correctly in all places, there is no technical reason it wouldn't be possible to let the username field be a free form text field.
There is a different question about what characters to permit in usernames. Though it is technically possible to support free form usernames, it is not necessarily a good idea. There are sound arguments for limiting the set of characters permitted in usernames, but those arguments have nothing to do with SQL injection.
Limiting usernames to only ASCII characters is useful if they ever need to be communicated through channels where you are unsure about encoding.
Limiting usernames to characters which are located in the same location on different keyboard layouts is useful if you are working in an international environment. But I wouldn't enforce such limitations in software, because the set of keyboard layouts used by each user differs.
Preventing usernames which are visually identical can be a good idea in systems where it is important to be able to recognize a username. This means no non-printable characters. And if two characters look the same only permit one (this is rarely an issue if you stick with only ASCII characters). And spaces cannot be permitted at the start and end of the username, neither can two spaces next to each other be permitted.
And remember that restricting which usernames are permitted is not a substitute for generating your SQL safely.