"two additional scary prompts that you have to click Yes to"

Well, the User can uncheck the checkmark in your example. The worst you could do is fail to handle the scenario where the user unchecks that checkmark (a lot of sites/systems fail that). Most people are familiar with the Oauth flow that gives them the heads-up on what personal data will be shared between services. Your interpretation of scary is not the same as the next person's. Similarly, not everyone is scared of spiders.

"I do not need birthday to be that accurate"

Oh, so you aren't doing this to comply with some age restriction compliance requirement? You probably should, but it depends on the nature of your system and its content.

"Personally I'd be fine with the flow of enter in some random BS birthday -> later update it in my profile when I realize it would benefit me"

So choose for the user, get it wrong, make it obvious to the user, then relying on them caring about it enough to go and update it. If it is wrong, well...who knows what purpose you are actually using it for?? What are you actually using the "inaccurate birthday date" for?

"users are able to change it later anyways."

Really? In your system or in Facebook/Google? If they can change it later in your system, why not leverage that existing mechanism? E.g. auto-navigate to that mechanism upon first-time signin (or subsequent signins if not yet entered).

"two additional scary prompts that you have to click Yes to"

Well, the User can uncheck the checkmark in your example. The worst you could do is fail to handle the scenario where the user unchecks that checkmark (a lot of sites/systems fail that). Most people are familiar with the Oauth flow that gives them the heads-up on what personal data will be shared between services. Your interpretation of scary is not the same as the next person's. Similarly, not everyone is scared of spiders.

"I do not need birthday to be that accurate"

Oh, so you aren't doing this to comply with some age restriction compliance requirement? You probably should, but it depends on the nature of your system and its content.

"Personally I'd be fine with the flow of enter in some random BS birthday -> later update it in my profile when I realize it would benefit me"

So choose for the user, get it wrong, make it obvious to the user, then relying on them caring about it enough to go and update it. If it is wrong, well...who knows what purpose you are actually using it for?? What are you actually using the "inaccurate birthday date" for?

"users are able to change it later anyways."

Really? In your system or in Facebook/Google? If they can change it later in your system, why not leverage that existing mechanism? E.g. auto-navigate to that mechanism upon first-time signin (or subsequent signins if not yet entered).

Sounds like the most important thing you need to focus on is having the User accept terms of service (and privacy policy) prior to registration. Requiring (in those terms) that Users are over the age of 18 and capturing their acceptance of the terms means you can create the account without having the birth date value. You can't both accept an inaccurate birth date and require users to be over the age of 18 prior to creating the account and prove that with an inaccurate birth date. If you really need the birth date to prove their legitimacy, then you need a KYC flow (probably involving the collection and acceptance of a proof of identity card|driver's license|etc).