To address your primary question: a username is largely security neutral. NIST doesn't really have specific guidelines dictating what usernames a system should require. On page 21 of NIST Special Publication 800-63-3 (Section 4):
..the RP (relying party) may request the CSP (Credential Service Provider) assert information about the subscriber, such as verified attribute values, verified attribute references, or pseudonymous identifiers (i.e. your account number). This information assists the RP in making authorization decisions. An RP [..] may only need specific attributes, resulting in the subject retaining some degree of pseudonymity. This privacy enhancing approach is a benefit of separating the strength of the proofing process from that of the authentication process.
From a security perspective: how a username is determined is often the least critical part of the entire authentication design process. Is it ideal for you to have a username that both identifies your bank down to the branch (your sort code) in combination with your account number? No. Is it the ideal way for a relatively large system to assign potentially tens or hundreds of thousands of usernames to unique individuals across multiple geographic locations? Probably, yes.
To address your specific situation: yes - as you have already outlined, it is less secure to have your username be your account number than it would be to set it yourself - but it's also more secure than having firstinitial.lastname or some other similarly structured syntax.
Based on whom you are considering making your complaint to, I am going to assume you are in the UK - so you may be able to find more specific guidance for UK and the EU (while you guys are still in it). By all means - make a complaint if you think it might help the situation, just keep in mind that there is no legal way for you to know for sure whether or not they are storing user passwords in plain text on their systems. In my opinion: being unable to change your password is the biggest red flag in the whole situation - so that might be where you can find some traction.
To address your points:
- Whilst my bank account number is not necessarily secret (it is printed on cheques, and I need to give it to people to transfer money to me), it seems needlesly open.
Your bank account number is as open as you allow it to be. Only write checks/give your routing information to trusted parties, secure your mailbox as best as you can, and if all else fails - choose another bank or change your banking practices. If your trust issues conflict with whatever convenience/benefits you are gaining, that is your decision to weigh.
- While most other websites also don't allow you to change your username and pre-set your username to your email address, in that scenario I at least have the option to create a throwaway email address, or use a + address.
This depends completely on the organization/company/system you are dealing with - in most cases dealing with money/bills where your account is automatically generated, you won't get to pick.
- It limits usernames to a single character set (numeric) which makes it easier for brute force hackers etc.
No one is going to brute force your username. Someone getting into your e-mail (and retrieving your password), gaining access to your [hopefully hashed] password from the benefits system, or logging your password because the computer you use to access the site has been compromised are the real issues here.
- Someone hacking my account will be able to gain the following information about me:
• Name
• Address
• Sort code
• Account number
• Email address
• Phone number
If someone is hacking your account specifically (as opposed to passive collection or downloading as many user credentials as they can), you can probably assume that all of those pieces of information are what they are already working with. Most of that (and including your date of birth) will be publicly available anyway, most of it is written directly on your checks, etc.
In conclusion: if you are making a complaint, include everything you can prove - maybe even what you expect is happening on the backend - but don't get your hopes up.