If you want this to take off, you really need to provide a mechanism for exporting it to a wide variety of large resume handlers (monster, various large employers, etc.) and importing (e.g. from linkedin).
It's boring and tedious work, and the number of edge cases will multiply geometrically, but it's likely the only kind of thing that would make this take off.
We were nearly going to do a brand change because JSON and YAML are interchangeable and it doesn't really make any sense to just promote JSON in this case. I also love YAML, the problem was writing specification's seems a lot more mature when you follow the json-schema.org project. So I thought why not write it initially in JSON with the json-schema project as a basis and then just supply the tools for people who prefer YAML.
Ugh, json schema is horrible. Have you used orderly? It's far less verbose, more readable and it compiles to json schema.
I agree that making it interchangeable is best overall (especially since there is a 1:1 convertibility between the two languages).
Perhaps the brand should actually reflect this instead. JSON is preferable in a data interchange scenario, but for keeping or displaying a human readable version, YAML is better.
As before, though, it's not YAML/JSON - it's the richness of the import/export filters that will make this idea float or die. Nobody much is going to want this so that they can publish their resume on jsonresume.org. People will want to use it so they can efficiently and easily import their linkedin resume and upload it to [insert fortune 500] company's custom HR portal / top 7 job sites.
Otherwise you have the xkcd problem: http://xkcd.com/927/
It's boring and tedious work, and the number of edge cases will multiply geometrically, but it's likely the only kind of thing that would make this take off.
P.S. Why not YAML?