Access-control-allow-origin: * with a bearer token

There are a few things that will mean exploitation is unlikely.

To start with

access-control-allow-credentials: true
access-control-allow-origin: *

is an invalid combination:

Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding. The above example would fail if the header was wildcarded as: Access-Control-Allow-Origin: *. Since the Access-Control-Allow-Origin explicitly mentions http://foo.example, the credential-cognizant content is returned to the invoking web content.

Another thing is that the authorization header is not a simple header, so would require a preflight that results in an Access-Control-Allow-Headers response returning that header. The server not returning this would also prevent any CSRF attack, because the pre-flight will block it.

Unless it allows the header, it is not usually possible to add a custom header cross domain unless you attempt an exploit with Flash that used to work on certain browsers.

What are the risks with this model? Is this a sensible way to do things?

As it is invalid to specify this combination of headers, indeed this is not a sensible way to do things. There may be some odd browser out there that would allow it and the site would be vulnerable (should any potential victim be using it). Allowing all origins but not credentialed requests allows the victim browser to be used as a sort of proxy in order to reach otherwise inaccessible resources. However, as the bearer header cannot be attached (without a Flash exploit) and being allowed through Access-Control-Allow-Headers, I wouldn't say this is high risk. Additionally, as the attacker does not have their victim's bearer token, any cross domain requests that would be made would be under the attacker's session rather than their victim's.

I would probably point it out as an advisory item that they should review that their CORS headers match their intention.