Problem was simple. I had neglected to install both spamassassin and spamass-milter, I had only done the pkg install on spamass-milter.

  service sa-spamd restart
  spamd not running? (check /var/run/spamd/spamd.pid).
  child process [21277] exited or timed out without signaling production of a PID file: exit 255 at /usr/local/bin/spamd line 3034.
  /usr/local/etc/rc.d/sa-spamd: WARNING: failed to start spamd

  root@brix:~mikel/html/howto # /usr/local/bin/spamd 
  Apr 29 10:37:19.847 [21292] error: config: no rules were found! Do you need to run 'sa-update'?
  config: no rules were found!  Do you need to run 'sa-update'?

pkg install spamassassin
pkg install spamass-milter
New install instructs you to do the following:
sa-update
sa-compile

Edit /etc/rc.conf, add:
spamass_milter_enable="YES"
spamass_milter_flags="-r 10 -f -u spamd -p /var/run/spamass-milter.sock"
spamd_enable="YES"
spamd_flags="-d -u spamd -H /var/spool/spamd"

service spamass-milter start

ll /var/run/spam* -- check for spamass-milter.sock -- if not present, your problem is with spamass-milter. I had problems when I tried moving the socket to a subdir, so just don't.

Note that any time you make a change to your local.cf file, it's a good idea to do a quick:
spamassassin --lint

Edit /etc/mail/[your-system-name].mc, add:

dnl  Following limits size of file that will be sent to spamd, without this
dnl  spamass will simply skip parsing of large emails and let them through.
define(`SMTP_MAILER_MAX', `15000000')
define(`confMAX_MESSAGE_SIZE', `15000000')

dnl Added spamassassin 19-Apr-2005
dnl 20180422 upped S and R from 4m to 6m, added T val to F switch
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass-milter.sock, F=T, T=C:15m;S:6m;R:6m;E:10m')

define(`confMILTER_MACROS_CONNECT', `b, j, _, {daemon_name}, {if_name}, {if_addr}'})

define(`confMILTER_MACROS_HELO', confMILTER_MACROS_HELO``, {verify}'')

dnl 20140302 - getting msg Could not retrieve sendmail macro "b"!
dnl in logfile.  see:
dnl http://lists.gnu.org/archive/html/spamass-milt-list/2006-05/msg00011.html
define(`confMILTER_MACROS_ENVRCPT', ``b, r, v, Z'')

define(`confINPUT_MAIL_FILTERS', `spamassassin')

Sep  5 14:13:05 pedicel sm-mta[27634]: w85LCRct027634: milter_sys_read(spamassassin): cmd read returned 0, expecting 5
Sep  5 14:13:05 pedicel sm-mta[27651]: w85LCteO027651: Milter (spamassassin): read returned -1: Connection reset by [89.238.132.202]
Sep  5 14:13:05 pedicel sm-mta[27634]: w85LCRct027634: Milter (spamassassin): to error state
Sep  5 14:13:05 pedicel sm-mta[27651]: w85LCteO027651: Milter (spamassassin): to error state
Sep  5 14:13:05 pedicel sm-mta[27651]: w85LCteO027651: Milter (spamassassin): init failed to open
Sep  5 14:13:05 pedicel sm-mta[27654]: w85LD1LA027654: Milter (spamassassin): read returned -1: Connection reset by ns508073.ip-192-99-7.net
Sep  5 14:13:05 pedicel sm-mta[27651]: w85LCteO027651: Milter (spamassassin): to error state
Sep  5 14:13:05 pedicel sm-mta[27651]: w85LCteO027651: Milter: initialization failed, temp failing commands
Sep  5 14:13:05 pedicel sm-mta[27654]: w85LD1LA027654: Milter (spamassassin): to error state
Sep  5 14:13:05 pedicel sm-mta[27654]: w85LD1LA027654: Milter (spamassassin): init failed to open
Sep  5 14:13:05 pedicel sm-mta[27654]: w85LD1LA027654: Milter (spamassassin): to error state
Sep  5 14:13:05 pedicel sm-mta[27654]: w85LD1LA027654: Milter: initialization failed, temp failing commands
Sep  5 14:13:05 pedicel sm-mta[27634]: w85LCRct027634: Milter: data, reject=451 4.3.2 Please try again later
Sep  5 14:13:05 pedicel spamc[27644]: oops! message_dump of 8192 returned different
Sep  5 14:13:05 pedicel sm-mta[27634]: w85LCRct027634: to=, delay=00:00:38, pri=656529198, stat=Please try again later
Sep  5 14:13:05 pedicel spamc[27644]: oops! message_dump of 8192 returned different
  

This can be verified by going out to a command line and doing:
telnet localhost smtp
EHLO localhost
Look for the "SIZE" line - it is not followed by a number - it has no value on my system. To fix this, in .mc file add:
define(`confMAX_MESSAGE_SIZE', `10000000')

NOTE! This command requires the "conf" prefix. The related SMTP_MAILER_MAX CAN NOT have the "conf" prefix.
Of course don't forget to make .cf file, copy that to sendmail.cf [see comments on this below], then restart sendmail, and this time you should be able to see it in the telnet/EHLO.

This does seem to have fixed the crashing. I guess spamd has a bug related to large files, but that's not up to me to fix - I'm ok with limiting email size. Currently running 15Mb, I'll try to remember to come back here if that still has problems.

Suddenly I'm seeing the following message in my maillog:

Mar 2 02:07:21 systemname spamc[6286]: skipped message, greater than max message size (512000 bytes)
Mar 2 02:07:21 systemname spamass-milter[93284]: Could not extract score from <>

First task is to look through your maillog in an editor and search for "skipped", and check out the sizes of the mail causing the skip. Pick a nice slightly larger number. Most of my obvious spam oversized mails were ~549k, so I'm rounding up to a nice 600k. I'm leery of going up to 1MB as I don't know what the performance hit will be, but I'll keep an eye on it.

If interested spamc config file help, for details on the file format and options, there was no problem finding this. The one I'm concerned with is simply '-s'.

Here's the tricky part... When searching for where the config file should go, all the different locations I found mentioned were bogus, or at least did not work on my FreeBSD 5.4 system. Some claimed the file should be called 'spamassassin', but eventually I found one that said it should be 'spamc.conf'. What finally works on my system is:
/usr/local/etc/mail/spamassassin/spamc.conf

In the config file add the line:
-s 600000
[20200316] Am now using 25000000

03/26/14
Revisited logfile. Am seeing scantimes up to 19 seconds with a setting of 1024000. I have hundreds, possibly thousands of distinct rules to be parsed. The machine is possibly 10 year old dual proc 1.8(?)GHz with 15krpm scsi, probably only 4G ram. A modern machine would do much better, so it's probably safe to go with an even bigger number.