We could debate the design of the 404 code and perhaps you could devise some way to differentiate no resource found at a valid path branch. I think though, when you start thinking about other scenarios, this isn't straight forward. What about a URI where the resource is defined by multiple parts of the path that may or may not exist? For example, you could have
https://foo.com/resources/<parent>/<child>. The web is designed for everyone, not just your application so the idea that standards should match your exact desires is not realistic.
Regardless, when working in technology, you either need to accept certain things, find an alternate solution, or create your own. It's highly unlikely the way 404 is used and interpreted is going to change for you.
I see a few solutions here. It's absolutely possible to build a web application that doesn't throw a 404 in this situation. You just need a generic HTTP handler. For example, if you drop to something like the classic Java Servlet framework, you have to parse the URI yourself and it's up to you to determine when you throw 404 (and most other errors aside from 500.) You could absolutely return a non-error response when you a request where the resource id is not there. There are surely such APIs in most all languages that support REST frameworks that those frameworks use. You might even be able to customize your REST framework to do as you wish.
Personally, I think you'd be better off accepting this and figuring out how to work with HTTP error codes as they are. No matter how strongly I think driving on the right side of the road is correct (it's literally called the 'right' side), if I'm in the UK or India, I'm sure to have problems if I don't drive on the left.
In what scenario do you expect to have 404 errors for something that is not a result of a missing account? If your base path is wrong, that seems like a fatal error for your client. Or is it simply your understanding that "... browsers tend to treat 404s as actual errors before the request even reaches the app code". If it's the latter, I don't think that's the case. It's not my experience. If you have that issue, I'm guessing its something in a client library. Typically these should offer some way to customize the behavior on errors. You could use that to check for the 404 and intiate creation of the account.
Another option is could modify your API to have a query type operation. For example. have a query parameter like
accountexists resource will always exist and you can then return whatever you like to describe the existence and/or state of the account.