It was just according to the Singleton pattern there's a static function that returns a instance of the class, which is then called upon.
Instead of mine which is calling static functions of the class.

Yes, that's a choice. You can go both ways.

1) Make all functions + members static
2) Make only the "GetInstance" method static and use the instance it returns to call the non-static member functions. The point is that you can call "GetInstance()" on the class without an instance, thus no need to pass the instance around.

Here's your class definition changed to be a Singleton:

namespace Pro
{
	typedef unsigned int GUID; 

	class GUIDLookup 
	{   
	private:

		GUIDLookup(); // constructor is private
		static GUIDLookup* mInstance; // private instance


	public: 
					 
		static GUIDLookup* GetInstance()
		{
			if(!mInstance) mInstance = new GUIDLookup();
			return mInstance;
		}

		// all other non-static public methods
		// can be called after getting the instance with the method above
		GUID newGUID(const std::string& name);
		void releaseGUID(const std::string& name);
		void releaseGUID(GUID);
		GUID getGUIDFromName(const std::string& name);
		std::string getName(GUID _id);

	}; 

}

Edit: Oh and you'll have to intialize the mInstance variable to 0/NULL in a static initializer in the implementation file like so (and a better name would probably be msInstance, but it's too early in my timezone :

GUIDLookup* GUIDLookup::mInstance = 0;

About structure for this specific problem:

In this case I would not make this class a singleton either. As there's usually some sort of "Game/Application" class already that's responsible for creating instances of all subsystems on start-up, and seeing as this particular class is naturally a singleton as there can be only ever one instance of it, that is a good place to just create and put getters for your "global tools" there.

So you'd make the master "Game" class create an instance of your GUIDManager once and have a GetGUIDManager getter to let all other subsystems have access to it via "Game".

Sure it could all be structured differently, but this way you avoid making a lot of singletons (bad!) and using the one you already "have to" make anyway.