I have a different take on ralu's accepted answer and some of the comments thereafter.
Consider two $N$-bit data sequences which we think of as
polynomials
$$D^{(1)}(x) = \sum_{i=1}^{N-1} D_i^{(1)}x^i
~~\text{and}~~D^{(2)}(x) = \sum_{i=1}^{N=1} D_i^{(2)}x^i$$
where each $D_i^{(1)}$ and $D_i^{(2)}$ is $0$ or $1$. Let $M(x)$
of degree $64$ denote the CRC polynomial. Actual CRC
implementations for data communications have many bells and whistles
but let us assume that for hashing purposes, the simplest form
of CRC is used so that
the CRC check sums (or hashes) $R^{(1)}(x)$ and $R^{(2)}(x)$ of
degree $63$ or less (and thus having $64$ bits) are
are the remainders obtained by dividing $x^{64}D^{(1)}(x)$ and
$x^{64}D^{(2)}(x)$ by $M(x)$. Rememeber that this is polynomial division
over the binary field $\{0,1\}$ where addition (and subtraction) is the
Exclusive-OR operation $\oplus$.
We thus have
$$\begin{align*}
x^{64}D^{(1)}(x) &= Q^{(1)}(x)M(x) \oplus R^{(1)}(x)\\
x^{64}D^{(2)}(x) &= Q^{(2)}(x)M(x) \oplus R^{(2)}(x)
\end{align*}$$
where $Q^{(1)}(x)$ and $Q^{(2)}(x)$ are the quotients.
Adding these two equations, we have that
$$x^{64}\left[D^{(1)}(x)\oplus D^{(2)}(x)\right]
= \left[Q^{(1)}(x) \oplus Q^{(1)}(x)\right]M(x)
\oplus \left[R^{(1)}(x) \oplus R^{(2)}(x)\right]
$$
It follows that if $R^{(1)}(x) = R^{(2)}(x)$ so that
$[R^{(1)}(x) \oplus R^{(2)}(x) = 0$, then it must
be that $D^{(1)}(x)\oplus D^{(2)}(x)$ is a multiple of $M(x)$.
Conversely, if $D^{(1)}(x)\oplus D^{(2)}(x)$ is a multiple of $M(x)$,
then so is
$$x^{64}\left[D^{(1)}(x)\oplus D^{(2)}(x)\right]
\oplus \left[Q^{(1)}(x) \oplus Q^{(1)}(x)\right]M(x)
= \left[R^{(1)}(x) \oplus R^{(2)}(x)\right]$$
a multiple of $M(x)$, and therefore $R^{(1)}(x) \oplus R^{(2)}(x)$
of degree $63$ or less is a multiple of $M(x)$ of degree $64$.
Since this can happen only if $R^{(1)}(x) \oplus R^{(2)}(x) = 0$,
that is, $R^{(1)}(x) = R^{(2)}(x)$, we have the following.
$D^{(1)}(x)$ and $D^{(2)}(x)$ hash to the same check sum,
that is, $R^{(1)}(x) = R^{(2)}(x)$, if and only if
$D^{(1)}(x)$ and $D^{(2)}(x)$ differ by a multiple of $M(x)$
This result holds even if $D^{(1)}(x)$ and $D^{(2)}(x)$
are of different degrees if we zero-pad the shorter sequence
with zeroes at the high-order end to make the sequences of equal
length. But if the afore-mentioned bells and
whistles are included (e.g. complement the high-order two bytes before
commencing CRC calculations), then the result still holds for
equal length data sequences, but should not be applied blindly
when $D^{(1)}(x)$ and $D^{(2)}(x)$ are of different degrees:
some care is necessary.
For the simple case considered here, we have immediately
that
$$\deg D^{(1)}(x) = \deg D^{(2)}(x) = N-1 \geq \deg M(x) = 64$$
and so if $N \leq 64$, we are guaranteed that no two sequences
hash to the same checksum.
Turning to further specifics and ralu's answer, each alphanumeric symbol
can have one of $62$ different values, and while it is possible to
map $11$ such symbols to $62^{11}$ different bit sequences
of lengths $64$ or less, it is much more convenient
to implement a symbol-by-symbol mapping into $6$-bit bytes
and create a degree-$65$ data sequence $D(x)$ of $66$ bits to be hashed.
The downside is that
four sequences $D(x), D(x)\oplus M(x), D(x) \oplus xM(x)$,
and $D(x)\oplus
(1\oplus x)M(x)$ will have the same hash, and this is the price
paid for simplicity of the mapping algorithm: we have to restrict
ourselves to $10$ alphanumeric symbols to avoid collisions.
On the other hand, compressing $11$ alphanumeric symbols to
$64$ bits or less is a messy task.
An even simpler method is to use the password as entered by
the user (say as a sequence of ASCII-encoded $8$-bit bytes) to create
the data sequence by concatenation. Now, $8$ symbols guarantees
no collisions as per the simplified analysis above, but the
actual picture is somewhat different. Although with $9$ bytes
and $72$ bits, collisions can occur, it is not immediately
obvious that collisions will occur. For example, $D(x)\oplus M(x)$
might well be a sequence of bytes that cannot be entered by
the user as a password because some of the ASCII characters are
control characters that cause the computer to take other actions
than to simply pass the character on to the application to be
processed.
I doubt there is a simple answer to the question of what is
the maximum password length for which collisions are guaranteed
not to occur. The answer depends on the choice of $M(x)$
also. For example,
Wikipedia's page on CRCs
says that CRC-64-ISO $x^{64}+x^4+x^3+x+1$ is weak for hashing purposes,
the basis of which claim the diligent reader of the above will have no difficulty
understanding.