Let me start off by saying that I read other StackExchange questions related to this and they weren't really able to answer my question. I have a feeling this may be an unsolvable problem, but I'm wondering if maybe there's a happy medium that will satisfy my requirements.
I have an Android application. However, it's not login-based in the traditional sense that users don't sign up with an email or anything. We just automatically create an account for them with some randomly generated UUID as their "login" to the service. To get this UUID, the Android application sends a request to a webservice indicating that they are a new user who just installed the application. The webservice then returns a UUID that will be used for any further accesses to the application. The point of this is to make it so that user specific information can still be stored in the database, but users don't have to go through the hassle of creating an account and logging in every time.
Obviously, requests to the webservice for other actions are all restricted by having a valid UUID. However, the webservice for creating the account has no restrictions, meaning an attacker could spam GET requests to it from any device to create any number of users they want and flood the database/server.
My question is, how can this be avoided? I understand the concept of a secret embedded in the Android application to access the webservice, but it seems like any client-generated secret could be easily obtained by an attacker by decompiling the APK. Another idea was to restrict access by MAC address, meaning only MAC addresses with the app installed could reach the user creation web service URL. But because of MAC-spoofing, that also seems like a bad idea.
Is there a good way to have a client-generated secret that isn't easy to obtain by examining source code? I know this is a very difficult question but if anyone has some insight that would be great.