If you want to demonstrate the properties of a good cryptographically secure hash, you could start with a non-cryptographically secure hash, and show why collisions are bad, why reversibility is bad, and why allowing modifications is bad. Once they've learned the "bad", they should better understand why those properties make a cryptographic hash "good".
The Luhn algorithm would be a good choice for pencil and paper attacking. It's a real world hash algorithm used on credit cards and barcodes, and produces what is commonly called a "check digit". In reality, it's no more than a very simplistic hash of the previous digits, and was originally developed to help guard against keying errors. Collisions are easy to find. Depending on the length of the input, it's generally not reversible (however if you feed it only a one digit input, it's certainly 100% reversible.)
If you'd rather use a real cryptographic hash (one that will require a computer) you could artificially reduce the size of the produced digest using the modulo function. Take a SHA-2 hash and divide the digest modulo 256. That will give you a one-byte hash value, which should be trivial to find collisions for. Expand it to two bytes, and the students will see that it gets harder. Continue expanding it out to the full 32 bytes, and collisions will quickly stop being so easy.