Restricting to run-of-the-mill Elliptic Curve Digital Signature Algorithm and curves as in [FIPS 186-4 appendix D][1]:

- an $m$-bit curve, that is one over field $GF(2^m)$ with $m$ prime, or over field $GF(p)$ with $\log_2(p)\approx m$ and $p$ prime (and possibly of some special form), allows schemes with $m/2$-bit security (at most, but we can largely ignore that for well chosen curves as far a we know).
- [Challenges][2] at the level $m=109$ have been publicly solved circa 2002. I'm not aware of security authorities ever vetting anything less than $m=163$ for any use, but it is technically sound to use $\log_2(p)\approx128$ as in curve secp128k1 for copy-protection (which can likely be broken by other ways that forging a signature).
- A point on an elliptic curve (that is not the special point at infinity) can be expressed in a variety of forms, at least two of which being common for representing a public key or a signature:
  - Cartesian coordinates $(X,Y)$ verifying $Y^2=X^3+aX+b$, where all terms and operations are in the base field $GF(2^k)$ or $GF(p)$, with $a$ and $b$ fixed public curve parameters;
  - compressed Cartesian coordinates $(X,\text{sign})$ where a single bit $\text{sign}$ allows to choose among two solutions for $Y$ of the equation $Y^2=X^3+a\cdot X+b$.
- A public key or signature is a bitstring allowing to designate a point on the curve; that's requiring $2k$ bits using Cartesian coordinates, or $k+1$ bits using compressed Cartesian coordinates (discounting overhead for encoding the bitstring into a conventional form such as ASN.1).
- It is further possible to gain a few bits (say $k=8$) by simply omitting them, and compensating for their lack. One method is to repeat the key or signature generation process until hitting a public key or signature where these $k$ bits are all zero. That increases the cost of public key or signature generation by a factor of $2^k$, which is acceptable in the context of copy protection; there is no loss of security whatsoever.
- If a signature is keyed-in (rather than copy-pasted), one wants to re-encode the corresponding bitstring as symbols chosen to minimize the risk that a keying mistake renders the signature invalid. The problem is different depending on if you have control of the font used to render the string keyed-in, or not. In the later (worst) case, as a courtesy to the paying user, you should restrict to decimal digits and roman letters without accents, ignoring case, grouping symbols into equivalence classes based on visual similarity, such as $\{\text{0},\text{O},\text{o}\}\;$, $\{\text{1},\text{l},\text{I},\text{i},\text{L}\}\;$, $\{\text{2},\text{Z},\text{z}\}\;$, $\{\text{3}\}\;$, $\{\text{4}\}\;$, $\{\text{5},\text{S},\text{s}\}\;$,... You will end up with perhaps $n\approx28$ of these classes, which could be stretched to $n=32=2^5$ with some extras like $\{\text{-},\text{_}\}\;$ and $\{\text{+}\}\;$ (when $n$ is a power of two, the re-encoding is slightly simplified).

So at the end of the day, the fixed number of symbols required to encode a signature is $\lceil(m+1-k)/\log_2(n)\rceil$. For secp128k1, $n=28$, that can be $25$ symbols, like `7RPGE 10VGVH KX7P1 KPMG8 RABKY`. An extra complication of the signature generator is that it might be required to avoid signatures containing politically incorrect substrings (I've always wondered if the dominating OS and desktop vendor does that), but it will only moderately complicate the generation.

  [1]: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf#page=96
  [2]: https://www.certicom.com/index.php/the-certicom-ecc-challenge