There are several questions which I will answer individually:
How to download (and not install) individual binary package?
apt-get has an option to only download the package:
-d Download only - do NOT install or unpack archives
You will find the downloaded package in /var/cache/apt/archives/. In this case you will have to add a new sources list configuration to apt.
How to download individual source package?
apt-get source <package>
or when you know the location of the .dsc file:
dget http://http.debian.net/debian/pool/main/k/knot/knot_1.2.0~rc3-1.dsc
Both approaches do verify the signature on the files
How to pin the sources.list aka how do I not mess my installation?
You have already pointed to the page of basic description for APT Pinning, and I would only add that you probably want to read the apt_preferences manpage which also have nice examples to accomplish things you need. Especially see the section 'Tracking Stable' in EXAMPLES, since it describes something very close to your needs:
There's an usefull command when playing with multiple sources and APT Pinning:
# apt-cache policy knot
knot:
Installed: 1.1.3-1~bpo60+1
Candidate: 1.2.0~rc3-1~bpo60+1
Version table:
1.2.0~rc3-1~bpo60+1 0
500 http://deb.knot-dns.cz/debian/ squeeze/main amd64 Packages
*** 1.1.3-1~bpo60+1 0
100 /var/lib/dpkg/status
1.0.5-1~bpo60+1 0
500 http://ppa.sury.org/debian/ squeeze/main amd64 Packages
This shows that the installed version is 1.1.3-1~bpo60+1, and candidate is 1.2.0~rc3-1~bpo60+1, which will get installed on next apt-get upgrade. Also there's some older version available from yet another repository.
How to download Debian archive key?
Debian archive key is published on ftp-master. You will need to import the key into your gpg keyring:
$ gpg --import archive-key-6.0.asc
gpg: key 473041FA: public key "Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 9 signed: 31 trust: 0-, 0q, 0n, 0m, 0f, 9u
gpg: depth: 1 valid: 31 signed: 38 trust: 25-, 0q, 0n, 1m, 5f, 0u
gpg: depth: 2 valid: 21 signed: 31 trust: 19-, 0q, 0n, 0m, 2f, 0u
gpg: depth: 3 valid: 3 signed: 12 trust: 2-, 0q, 0n, 0m, 1f, 0u
gpg: depth: 4 valid: 1 signed: 8 trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2013-09-22
Then you will have to check its signatures:
$ gpg --list-sig 473041FA
pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05]
uid Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
sig 3 473041FA 2010-08-27 Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
sig 7E7B8AC9 2010-08-27 Joerg Jaspert <joerg@debian.org>
sig P B12525C4 2010-08-27 [User ID not found]
sig D0EC0723 2010-08-27 [User ID not found]
sig 8AEA8FEE 2010-08-27 [User ID not found]
sig A3AE44A4 2010-08-28 [User ID not found]
sig 00D8CD16 2010-08-28 Alexander Reichle-Schmehl <alexander@reichle.schmehl.info>
sig CD15A883 2010-08-28 [User ID not found]
sig 672C8B12 2010-08-28 [User ID not found]
sig 2 C4CF8EC3 2010-08-28 [User ID not found]
sig 2 D628A5CA 2010-08-28 [User ID not found]
And track the individual GPG keys to Debian developers either by tracking it manually, or f.e. checking at PGP Key Statistics project. And unless there's a chain from your PGP/GPG key to the Debian key archive, you will have to make a leap of faith at some point of time.
How to download and verify individual packages by hand
So the other approach is more complicated, because deb packages are not signed individually, but only the Release file is signed. Thus you will need to download and verify the signature on Release and Packages files together with the individual package.
I will add an example that will be clearer.
Imagine you want to download Debian package for Knot DNS from it's official PPA for Ubuntu precise on amd64 architecture.
You will have to click through the directories and find these files:
wget http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/dists/precise/Release
wget http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/dists/precise/Release.gpg
wget http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/dists/precise/main/binary-amd64/Packages
wget http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/pool/main/k/knot/knot_1.2.0~rc3-1~precise+1_amd64.deb
The next step would be to verify the signature on the Release file:
$ gpg --verify Release.gpg Release
gpg: Signature made Fri 01 Mar 2013 07:14:38 PM CET using RSA key ID F9C59A45
gpg: Good signature from "Launchpad Datové schránky"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5246 3488 670E 69A0 9200 7C24 F233 1238 F9C5 9A45
Of course you'll need to verify the key in some other means (like the Debian/Ubuntu maintainers key, checking it from launchpad, etc, etc...)
When you have verified the correct signature on Release file you can go to next step – verifying the Packages file.
sha256sum Packages
c96a524398cf6e9db033c8299974fe324eba47cc8190efec6495c74e251330ad Packages
$ grep c96a524398cf6e9db033c8299974fe324eba47cc8190efec6495c74e251330ad Release
c96a524398cf6e9db033c8299974fe324eba47cc8190efec6495c74e251330ad 3379 main/binary-amd64/Packages
As you can see, the signature can be found in the signed Release file, thus we have verified the integrity of Packages file by computing and comparing its SHA-256 fingerprint.
The last step is similar. You need to compute and compare the fingerprint of the individual package:
$ sha1sum knot_1.2.0~rc3-1~precise+1_amd64.deb
8b34078e9bfef7aa818b2f926a28838b0ede9f43 knot_1.2.0~rc3-1~precise+1_amd64.deb
$ grep -A 13 "Package: knot$" Packages | grep "^SHA1: "
SHA1: 8b34078e9bfef7aa818b2f926a28838b0ede9f43
At this point we have securely chained the package to the signed Release file. So if you believe the signature on the Release file, you can be sure that the package was downloaded intact.
You can read more in Secure APT article at Debian Wiki.
Best Answer
If you're doing this for one-off packages for one-off clients, doing it the way you're doing sounds about right. They'll need to add the key, add the repo, update and then install. Bit of a long route but it can be boiled into a few commands. You could also distribute a script does the above for the user but even then you need to instruct them to chmod/run it.
If you're intending this for mass distribution (same package for lots of people) and want it to go on general sale, talk to Canonical. They have partner repos and private repos for software on sale. They'll want a cut though. You can read more about it on the developer FAQ and then just sign into the developer site to get started.