They can be protected as well, not just public and private.
The primary reason I can think of that one would make a pure virtual function private are for affecting the way that the object can be dealt with through pointers and/or references.
It all stems primarily from the fact that a virtual function can be called from a member function in the base, so the member function can be called from within the base class member functions, just not externally.
Also, remember that you can change the access of a member function in derived versions of the class. What's private in the base class isn't necissarily private in a child.
Let's say you have a pure virtual function in a class "Base," but you only want that function to be called through pointers to its children. In other words, you want to be able to call the function through a pointer to a child or an object of a child type, but never through a pointer to its base.
One solution would be to just not put the function in the Base class, but the problem with this is that it doesn't hold the logic that all of the children should have that member function. You want to keep that logic but make it so you can't explicitly call it through a pointer to a base object.
If, instead, you make the member function pure virtual and private, you're ensuring that people MUST make their own versions of that virtual function in the Base type's children if they want to instantiate those types.
Then, if necissary, the virtual function can be made protected, public, or left private, to take advantage of that access specifier.
Oh the many wonders of OOP
virtual void Func() = 0;
: public Base
virtual void Func();
: public Base
/* Stuff Goes Here */
Func(); // Perfectly valid
std::cout << "B\n";
//BadChild BadChildObject; //Invalid, Func was not defined
Base& BaseObjectReference = ChildObject;
ChildObject.Func(); // This works!!!
BaseObjectReference.DoStuff(); // This works!!!
//BaseObjectReference.Func(); //Invalid! Func is private!!!
EDIT: Disabled those smilies