Off the top of my head:

#ifdef COMPILING_X_DLL
#define X_EXPORT __declspec(dllexport)
#else
#define X_EXPORT __declspec(dllimport)
#endif

class X
{
protected:

  X();
  virtual ~X();

private:

  // Copyguard
  X(const X&);
  void operator=(const X&);

public:

  virtual void f1();
  virtual void f2();
  virtual void f3();

private:

  // Non-virtual implementation functions

public:

  X_EXPORT static X* Create();
  X_EXPORT static void Destroy(X*);
};

Then in x.cpp, implement all the functions except those in the Copyguard
section. If you need copying, you may have to implement those functions,
and if you want users to be able to make copies, you'll have to expand the
static section. You don't have to export the virtual functions, because
they are represented by pointers in the vtbl, and each object contains a
pointer (the vptr) to this table. Thus, you don't link to those functions
by name, and that's why you don't have to export them. You do have to
export the creation and deletion functions, because you have to be able to
link to them by name.

Of course, the weakness of following the documentation you quoted to the
letter is that derived classes can't call X::f1(), because that's a
statically bound call and does require linking by name. You can work around
that by adding X_EXPORT to the front of your virtual functions. But then
you're just about at the point where you might as well have exported the
whole class, which is what I recommend doing if you want the thing to act
like a C++ class instead of a COM-style interface. As long as you link
everyone to the same CRT DLL and consider this usage equivalent to static
linking WRT compilation dependencies, for the most part, it'll work fine,
and you can get rid of the Create/Destroy functions, as well as all the
individual function exports, and it'll "just work".