As a general approach to the design process, start with the simplest and add complexity only if indicated by user research.
If you have nothing, show nothing
A large blank space is usually a pretty good clue that you’ve nothing to show and input is needed, like a form with an empty text box. As long as the blank space is visually associated with the Category drop down (e.g., a frame comprises both), and the Category drop down label sufficiently communicates what the user gets (e.g., “Performance of Product Category: _ “), then no other prompting is necessary.
A simple blank space reduces the amount of reading and thinking the user has to do (your Option 1), and avoids the user confusing fake list data for real (your Option 2, second half). Users won’t necessarily know gray or other fading means “example” or “fake.” They might think it only means “disabled” (i.e., the values are real but can’t be edited), or maybe they think it’s just static graphic design, since gray-on-gray is a recent fashion in web sites and the user may have never seen the area when it has real data.
A large blank area may even motivate the user to select a category precisely because the blank space “doesn’t look right” and the user will seek to balance. If you do want to provide a stronger indication of what the blank area displays and you can’t show a default Category value to serve this purpose (see below), then display blank graphs and fields. That is, show the axis and titles of the graphs, but zero data (e.g., a white circle for the pie graph like you suggest), and show the column and/or row labels in the list, but blank list items.
Avoid having nothing -pick a default
However, unless usability testing has shown users ignore the Category dropdown, don't assume they will and build a substandard UI that only raises new problems such as the ones you describe, plus the ones I list in my comment.
There seems to be this myth in web app design that defaulting contributes to more errors than not defaulting. I don't think there's any evidence of that, except maybe for some very specific situations (e.g., Likert radio buttons in opinion surveys). It's likely true that more users confronted with a default value leave the control on that value than users select that value when they are forced to choose, but that doesn't necessarily mean users are making an error; it may only mean users don't care much what value it is.
Even if testing shows users erroneously ignore the Category, look for other solutions to the problem before opting for a solution that contributes to user effort, error, and confusion. That cure can be worse than the disease. For example, maybe you need to improve graphic connection between Category and the detail regions (it's pretty weak in your wireframe). Or maybe you need a better names for the options of Category so users know what they mean and what they'd want.
So your solution may be #3. Set the Category drop down to the first item on the list, which should probably be the most frequent, important, or illustrative choice (even if it is only slightly moreso than the others).
BTW I wouldn't assume the Gmail solution is a good one, even for Gmail. Lot's of big companies who you'd think would know better don't.