The main difference is extensibility. Because static methods are tied to a particular class, there's no way to use virtual method calls. (This is the reason that, as the last poster correctly stated, you can't implement an interface with static methods--by definition, all calls to interface methods must be delegated to an implementing class, and hence are virtual. Incidentally, the only non-virtual methods in Java besides static are those that are marked final.)
The purpose of a design pattern like Singleton is to address a problem that occurs in many different situations generally, and that's not usually possible unless you provide for extensibility. Since static methods cannot be overridden, they are not extensible. Singleton avoids this by keeping the instance of the class as a static member (and providing access to it with a static method), but the class itself is comprised of instance methods:
So the question is, what good is extensibility in this case? Even if you write a class Bar the extends Foo, Foo.getInstance() will always and forever return an object of class Foo (instance is a "new Foo()", not a "new Bar()").
In that case, you'd want to use the Abstract Factory pattern in combination with these two Singletons (Foo and Bar) to provide correct Singleton to other classes. In fact, usually when using Abstract Factory, you'd abstract the interface of the class returned by an AF so callers wouldn't know the class of the object they're using at all (they work with the interface, so they only know the type).
Check out
this article over at
Object Mentor for an interesting alternative to Singleton called the Monostate pattern.
sev