I would put the long (comment ...) as the namespace's docstring. In fact, I would split that in docstrings because you're essentially describing the system by parts in a centralized place, while you could describe it in each part. I would keep the overall "how this game/namespace works/is organized" in namespace's docstring.

Declare is meant for forward declarations, not to expose functions (that's what you're doing there, right?) I didn't see it used like that anywhere, but I like the idea!

(not= player nil) is just player!

In next-turn I would just use a map instead of case (you're essentially mapping, right?)

(defn- next-turn [game]
  (assoc game :turn
    ((get-turn game)
      {:none :none  ;; I haven't seen spacing to match vertically used too much, but I don't really dislike it
       :player1 :player2
       :player2 :player1}))  ;; Or the other way around `(the-map (get-turn game))`

IMHO, this isn't very idiomatic:

(def  get-play-state    :play-state)
...

Aren't you better off using :play-state directly? It offers no encapsulation or maintainability whatsoever (am I right guessing this came from an OOP-like mindset?) And you lose information: the fact that :play-state is a keyword. I guess you did it to expose the analysis functions, right? You're better off mentioning the acceptable keywords in the documentation for your public make-game. I would use either (:play-state game) or (game :play-state) (the second will throw a NullPointerException if game is nil, which isn't bad per se.)

This is obviously style but: same goes for Initial data for making new games. I would shove that data directly into the make-game. It'd be already obvious for me that those are the initial states (since you're just bulding a map!)

The code is pretty good. I didn't even read the long documentation text and got how it works in a quick glance. I had some troyble understanding how try-combination works (consider making it more readable) but unfortunately I'm a bit in a hurry. I'll come back later and review that too (consider "not easily readable" my review at the moment.)

That's my humble opinion. The rest is pretty good.

EDIT

(answer to comment)

@LiamGoodacre that's what I thougth. Clojure favors universal (i.e. reusable) behavior for types instead of "interface tied to type", so it's just the other way around compared to OOP where data and actions are heavily tied.

Don't disregard the docstring tips either. Try (doc function-or-namespace) in a REPL to see how important is to have documentation tied to functions/namespaces instead of spread throughout the code or in (comment ...) forms. Documentation generation tools use this metadata too, so it's generally a good idea to do this.

I had a hard time grasping try-combination. Consider reworking it a bit, or maybe just add some more info to the docstring like what's [one two three]. The current dosctring is not every useful, I know what the functions does just by reading the name... it tries combinations, and "Calculates if a winning combination has occurred." is just a fancy way of saying it tries combinations.

This is just a matter of style, but I dislike heavy use of partial, comp, etc. and would prefer #(nth state (dec %)). I think it's easier to read. I also prefer [a b c] or [x y z] to [one two three]. I had a hard time following you were just destructuring a simple array instead of getting some special values that deserved the long one, two, three names :)

Why don't you return the winner in try-combination? Do it like this:

(defn- try-combination [state [x y z]]
  (let [lookup #(nth state (dec %))
        player (lookup x)]
    (and (= player
            (lookup y)
            (lookup z))
         player)))

That way, calculate-winner could return the actual winner and not just the current player, being more correct and reusable IMHO, also allowing you to decouple it from the game and just depending on the current state (e.g. what if you need it later to show the winner in a GUI for recorded games where you only have the final :level-state?)

(defn- calculate-winner [state]
  (let [matching (partial try-combination state)
        winner (find matching winning-combinations)]
    (or winner  ; Short-circuit logic is cool for these tricks and VERY readable
        (and (some nil? state)
             :none)
        :draw))))

The more decoupled your functions are, the more reusable. Try working with the bare minimum data structures in a single function, instead of using complex maps.

I would also use a defrecord to define your game data structure.

(defrecord Game [play-state level-state scores turn])

Instance Games like any other Java class, e.g. for make-game :

(Game.
  initial-play-state
  initial-level-state
  initial-scores
  (random-turn))

The good thing: the map interface is still there!

IMHO, it offers some benefits: actually encapsulating the tightly coupled structures into an actual object (is there any benefit in the game being a simple map?), the map keys are "documented" as the record args and you can add interfaces to this object. E.g.: you could get rid of get-game-grid and implement it as java.lang.Object's toString, so you could do (str game) and get game's grid (a nice feature IMHO.)

You can also add customs protocols to these records to encapsulate the tightly coupled interfaces to your Game object (your Public Analysis Functions, although I would discard most of that.) Please note this is very OOP-y and should be kept to a minimum.

Finally: why bother defining functions as private? Screw encapsulation! You'll eventually need these functions outside your namespace for random uninentended tasks (specially if outside people interface with your game, it'd be a cool tic-tac-toe library), so keep these to a minimum (usually helper functions or functions that are tightly coupled with your namespace inner workings.)