FXCop does static code analysis of your managed code assemblies. Think of it as finding issues that will cause problems at run-time or that will affect how the developer believes the code will run (unreachable code).
StyleCop analyzes the structure of you code from a text point of view. Think of this as issues that will affect your development and design experience (Formatting, naming conventions, documentation)
They are both VERY valuable tools and you should use both but they do focus on different problems.
Stylecop is a style analysis tool that works at the source code level. It exists primarily to provide a single common style that managed projects can use to remain consistent within the larger world of managed software. It makes decisions regarding style primarily to avoid holy wars (after all, style is almost always an inherently subjective thing). I don't think I've ever met someone who liked all of StyleCop's rules, but that's ok. It means that StyleCop is a generally good compromise amongst the vast set of style guidelines that exist. (If stylecop's rules were highly customizable, beyond simply enabling/disabling them, it would defeat the entire purpose of the tool.)
FxCop, on the other hand, is a static analysis tool that works on the level of the managed assembly. It can be given directions via attributes because it can see attributes on code elements, e.g.. It detects problems that can be seen on the "binary" level (as it were) as opposed to the syntactic level.
To answer your question, StyleCop doesn't supercede FxCop, and FxCop doesn't supercede stylecop. They're two different tools with two different purposes that can both provide a real benefit for your code.
(AKA, I run with both. :) )
A couple examples of the things one might detect vs. things the other might detect:
StyleCop violations might include warnings related to: Whitespace, Formatting, Public method documentation via xml-comments, order of method definition within a class.
FxCop violations might include warning related to: Globalization, tight coupling, cyclomatic complexity, potential null dereferences.
An alternative or a good complement to FxCop/StyleCop would be to use the commercial tool NDepend. With this tool one can write Code Rule over LINQ Queries(namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default, these include design, architecture, code quality, code evolution, naming conventions, dead code, .NET Fx usage...
The strength of CQLinq over FxCop or StyleCop, is that it is straightforward to write a code rule, and get immediately results. Facilities are proposed to browse matched code elements. Concretely this looks like that: