I'll start my answer by saying that many people misunderstand the Same Origin Policy and what CORS brings to the table.
Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents CSRF. This is not the case. All the SOP does is prevent the response from being read by another domain (aka origin). This is irrelevant to whether a CSRF attack is successful or not.
The only time the SOP comes into play with CSRF is to prevent any token from being read by a different domain.
All CORS does is relax the SOP when it is active. It does not increase security, it simply allows some exceptions to take place.
Yes, some CORS requests cause pre-flight requests to be made before the actual request is made. The browser will make this pre-flight requests automatically, as necessary. These should not be thought of as any type of security mechanism - an old browser or a browser with CORS disabled will behave exactly the same as a browser did before the CORS specification. That is the request will be made without pre-flight.
I mentioned domains were different origins. Origins can also differ by port and protocol when talking about AJAX requests (not so much with cookies).
Finally, all of the above has nothing to do with forged requests coming from an attacker. Remember, the attacker needs to use the victim's browser for their attack. They need the browser to automatically send its cookies. This cannot be achieved by a direct curl request as this would only be authenticating the attacker in this type of attack scenario (known as "client-side attacks").
The benefit of CORS is that it allows your domain to allow reads from another trusted domain. So if you have http://data.example.org you can allow http://site.example.com that you also run to make AJAX requests and retrieve data from your API.